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 Wed, 16 Sep 2009 14:01:12 GMT
On Wed, Sep 16, 2009 at 1:38 AM, Curt Arnold <carnold@apache.org> wrote:
>
> On Sep 15, 2009, at 10:44 PM, Paul Davis wrote:
>>
>> Regardless of browser support, the first question should always be
>> weather we can avoid hacks specific to a user agent. Unless you can
>> show that there's a case where its absolutely impossible for a
>> significant user agent to configure itself to work properly I would be
>> at least a -0 on this.
>>
>
>
> I've seriously researched the issue since it is a critical issue in my use
> of CouchDB as apparently it was for the initial filer of the bug.  IE can be
> configured to immediately treat content as expired, however requiring users
> to change their advanced connection options in IE (which they may be policy
> be prevented from doing) or using a different browser.  Very good way of
> having a client decide that CouchDB is not an acceptable platform.  I hate
> having to deploy a branched CouchDB, but that is what I'm doing now.
>

I meant configuring in client code. Asking clients to change default
settings is ungood.

> You can add additional bogus random query parameters to interfere with
> caching, however that come at the cost of losing all cacheing, plus at least
> at the time originally posted some of the end-points did not accept
> unrecognized parameters.
>

Perhaps I read Christopher's original email wrong. I thought he was
indicating that there were XHR options to fix IE6 client side. If that
is indeed just random url crap I agree that its not a really real
answer.

>
>> Also, the spec fairly explicitly states:
>>
>>> The format is an absolute date and time as defined by HTTP-date in
>>
>> section 3.3.1; it MUST be in RFC 1123 date format
>>
>> And
>>
>>> To mark a response as "already expired," an origin server sends an
>>
>> Expires date that is equal to the Date header value.
>>
>> That pretty much says that neither a random historical date or value
>> of 0 is ever good. The place where it does mention 0:
>>
>>> HTTP/1.1 clients and caches MUST treat other invalid date formats,
>>
>> especially including the value "0", as in the past (i.e., "already
>> expired").
>>
>> Here it seems that the spec is specifically saying that this A Bad
>> Thing &trade; so much that it went out of its way to specify the error
>> condition. That's not the same as saying "its ok to send 0, any other
>> invalid date, or a date in the past".
>
>
> The spec appears to be walking a fine line with respecting behavior of some
> HTTP 1.0 caches that treated expires in the past as equivalent to no-cache.
>   See section 14.9.3, where HTTP 1.1 caches are instructed to assume
> no-cache if they see an Expires date in the past without a Cache-Control
> header.  CouchDB does send a Cache-Control, so we would not be affected by
> that.
>
> Within RFC 2616, the description of the treatment of "Expires 0", the note
> in section 14.9.3 and section 14.18.1, all seem to acknowledge the use of
> Expires in the long past.  RFC 2109 had this quote that indicated that at
> least in 1997, having a fixed Expires date in the past was a common pattern.
>
>> HTTP/1.1 servers must send Expires: old-date (where old-date is a date
>> long in the past) on responses containing Set-Cookie response headers unless
>> they know for certain (by out of band means) that there are no downsteam
>> HTTP/1.0 proxies. HTTP/1.1 servers may send other Cache-Control directives
>> that permit caching by HTTP/1.1 proxies in addition to the Expires: old-date
>> directive; the Cache- Control directive will override the Expires: old-date
>> for HTTP/1.1 proxies.
>>
>
> 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.
>

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.

> In my testing (as mentioned in the bug report), max-age=0 was insufficient
> to prevent stale requests if subsequent reads occurred within the same
> second.  I have not tested Expires == Date, but I think there is a
> possibility that some clients might still have a window where you can get
> stale depending on the client.  Setting max-age=0 is clearly within the spec
> and would likely reduce the user experiences of conflicts due to stale data,
> but would not be sufficient to get the unit tests to work unless you added
> explicit waits.

Just to be clear, its forbidden by the spec, but breaking compliance
to fix IE6 is something that should be considered.

I don't have the slightest on what major user agents would do if they
received their own date header back. The spec is pretty clear that it
means must-revalidate. It wouldn't surprise me if some of them thought
it meant cache for a second.

>
>>
>> Also I looked around the spec for a bit trying to find a logical
>> progression for when Expires applies vs ETag but couldn't find
>> anything. Though also importantly I didn't see "Clients are free to
>> use a heuristic in the absence of this header" clause. I'm well aware
>> that RFC's can be difficult to respect given their ambiguity in
>> places, but this appears to be another example of just making stuff up
>> though I could be convinced otherwise if there's a thread on a W3C ML
>> or something about why this heuristic exists.
>>
>>> I've monitored the traffic and the logs before and after the patch and
>>> see
>>> exactly what I would expect.  Second requests to unchanged documents get
>>> a
>>> 304 returned from the CouchDB and use the previously retrieved value on
>>> every browser I've tried.  Fire up Fiddler or your favorite network
>>> monitoring tool and see for yourself.
>>
>> Second requests from Safari get a 304 returned without the patch. Feel
>> free to fire up Wireshark. :)
>
>
> All clients that I've tested other than IE 6 return a 304 without the patch.
>  With the patch, IE 6 gets a 304 and all the other clients do too.
>  Christopher Lenz assertion was that if you applied the patch, that you
> would no longer get a 304 on the second request.  You can test his assertion
> by applying my patch to CouchDB and trying the test again.  If you no longer
> get a 304, then Christopher is correct and I've missed something, but I'm
> thninking that you will still see a 304.
>
>>
>> But in all seriousness, the real question is whether we're improving
>> the situation by fudging this aspect of the HTTP spec or not. The fact
>> is IE6 (as much as we all hate it) still has a noticeable market
>> share. Just kicking it to the curb would be expedient but isn't the
>> right answer either. The answer is that we need to make sure that it
>> can be made compatible, and if not then and only then should we
>> consider breaking HTTP as a special case.
>>
>> As Christopher Lenz mentions, if the concern is a working Futon on IE6
>> then adding smarts for detecting the browser environment and
>> configuring itself is a patch away. If its trying to force CouchDB to
>> make amends for a specific broken HTTP stack, that's another. Unless
>> it can be shown that its impossible for IE6 to fix itself there's no
>> reason to complicate every other client.
>
> My concern is not Futon on IE 6.  My concern is that I have to tell people
> that anytime they get a conflict message in my app, then have to close their
> browser, reload the site and redo their work.  None of my code is based on
> Futon or JQuery.
>
>
>>>
>>> The unconditional Expires header is the simplest fix.  As far as I can
>>> tell,
>>> it has no undesirable effects and accomplishes the goal.  If that doesn't
>>> go
>>> in, then I'd prefer to see the header values being configurable instead
>>> of
>>> baking in other logic.
>>
>> Configurable headers are a good idea. "X-Noah: Awesome" is something
>> that CouchDB should be able to do. Though I don't know what other
>> logic we'd be baking in unless you mean browser sniffing. Christopher
>> Lenz might've only been -0 on that, but I'd be -shitton.
>
> I took a shot at it before I submitted my patch, but I must have missed
> something since I couldn't get the info out of the configuration file.  I
> thought the more minimal patch was likely to be accepted.
>
>>
>>> I don't want to get in a reopen war, but please reopen the bug.
>>
>> As far as I'm concerned you haven't done anything to refute
>> Christopher's logic on why this isn't a bug. Feel free to open a
>> configurable headers ticket though because I think that'd be generally
>> useful.
>>
>> Paul Davis
>
> Christopher made an assertion that my patch broke all caching.  The bug was
> closed on that assertion.  I've done a lot of testing that is inconsistent
> with his assertion.  The code and the tools are there for anyone else to
> check our assertions.
>
> I didn't file the initial bug report, but I've encountered the same issue in
> my development.  It has been dismissed as a broken stack and fix it on the
> client side, however there is nothing like an easy client side fix.  I asked
> in May, if it wasn't going to get fixed server-side, then what was the
> client-side fix.
>
>

I'm convinced on custom headers.

Mime
View raw message