couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Call for objections releasing 0.10
Date Thu, 17 Sep 2009 05:39:42 GMT
On Thu, Sep 17, 2009 at 1:05 AM, Curt Arnold <carnold@apache.org> wrote:
> Sorry about the bad quoting, somehow the message evaded my email client.
>
> Paul Davis wrote:
>
>>
>>  I'm not really concerned with major user agents in terms of headers we
>> add. Most of those should be configured to do the right thing 99% of the
>> time regardless. The question is what would I do if I tried implementing a
>> client? Setting all of these caching headers may fix popular browsers, but
>> for those that want to speak raw HTTP it just complicates the crap out of
>> everything.
>
> IE 6 can be reconfigured to use a different heuristic to determine whether a
> doc is stale and needs to be revalidated when there is not an explicit
> Expires or max_age.   IE 6's default behavior is documented (link in the bug
> report) and as far as I can tell is not invalid.  I don't see any explicit
> statement in the spec on what a client should assume for an expiry date when
> one is not provided by the server.   MS just decided something different
> than the other implementers.  It is not a desirable thing to try to convince
> a client that they need to change some advanced setting to get your app to
> work.

Firstly, I agree that changing a default browser config to make things
work better is the least desirable solution. So much that I wouldn't
even consider it as one.

On principle though, just because something isn't mentioned in the
spec doesn't mean that an implementation gets to invent. In this case
as I read things the most correct solution when receiving a response
with no Expires header would be to not cache based on time span.

> I do not see how providing a nearly universal HTTP 1.0 Header in the
> response would in anyway complicate any thing for someone writing their own
> HTTP stack.   It seems highly unlikely that any significant HTTP stack would
> be impacted by the addition of an explicit Expires header instead of the
> current reliance on an implied expiration.

Like I said, I'm not concerned about the significant players in the
HTTP world. They have enough experience dealing with the oddities that
pop up that they probably get it right. What I'm specifically
concerned about is if *I* have to write a client to deal with
CouchDB's output. Either I write something to spec and reject the
oddities, or I start allowing exceptions to the spec to creep in
because the big players do it.

>>
>> Just to be clear, its forbidden by the spec, but breaking compliance to
>> fix IE6 is something that should be considered.
>
> What specifically are you saying is forbidden by the spec?  The preceding
> paragraph is talking about "Cache-Control: max-age=0" which I can't make any
> case for reading as forbidden by the spec.  It reduces the incidences of
> stale data, but still leaves a 1 second window at least in the browsers I've
> tested.
>

I quoted wrong, what I was referring to was this:

> The HTTP spec is pretty clear that any bad date value should be interpreted
> as in the past (which is what we want).  It seems farfetched that any reasonable
> client would do the wrong thing with an old date.

The spec says that Expires must be a valid RFC date in the future.
This means that passing Expires: 0 is invalid, just as Expres:
"date-in-past" is invalid. So by triggering the specified error
condition we are breaking the spec. Like I say, pragmatically most
implementors would get it right, but we can only tell the
implementations to get it right by being wrong.

>> > I'm convinced on custom headers.
>
> I'm not sure how to interpret that statement.  I'd like to interpret as an
> willingness to consider for configurable headers.

Absolutely! Its on my whiteboard. Configurable headers are an
excellent solution here because they're a generic feature that can be
used to solve the issue at hand. As much as I dislike adding hacks for
specific user agents, I do like adding generic capabilities to allow
flexibility.

HTH,
Paul Davis

Mime
View raw message