Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.210.193 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=WAWPotCXuszKQLO0+c+ZINEaWWrkOTSrkdozDyHV92p+1PLU9AzIegcWidRIYAOrwx
         FhgRwUoR114jCpT1woXvG0ytkAoGwptWuHj++ou/IYZn7+g7496hAUxzS1pDX7Mz1SP1
         isG/TxEWUWgfRsNvO5DQAcGIJ/tJMKunwxjg8=
MIME-Version: 1.0
In-Reply-To: <7AAA2D9C-AF97-45CF-B1AD-B7BDFA98478F@apache.org>
References: <20090915100056.GH2578@tumbolia.org>
	 <E5156198-3CB3-4978-8795-68E1AB897609@apache.org>
	 <8E8DEA5C-7624-417A-B70F-C1FB77A9FBF9@gmx.de>
	 <7AAA2D9C-AF97-45CF-B1AD-B7BDFA98478F@apache.org>
Date: Tue, 15 Sep 2009 23:44:29 -0400
Message-ID: <e2111bbb0909152044m495c1b92he0986cd18e3dedbd@mail.gmail.com>
Subject: Re: Call for objections releasing 0.10
From: Paul Davis <paul.joseph.davis@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 15, 2009 at 10:55 PM, Curt Arnold <carnold@apache.org> wrote:
>
> On Sep 15, 2009, at 5:30 PM, Christopher Lenz wrote:
>>
>> This is a somewhat misleading description; it's not the lack of an Expir=
es
>> header on CouchDB responses that results in incorrect caching, it's a
>> (really ugly) bug in the XMLHttpRequest implementation of IE6 that does
>> this. As far as I know, the cache control headers sent by CouchDB are
>> absolutely correct according to the HTTP specification. Unconditionally
>> adding an Expires header (with a date in the past) just to workaround th=
e
>> XHR bug in IE6 *completely disables* any caching by any user agent!
>
> One of the earlier patches did, but the current patch has no negative eff=
ect
> on other browsers (other than adding 20 or so bytes to the header) and
> brings XmlHttpRequest's behavior into line with the other browsers. =A0Ad=
ding
> Expires in conjunction with the must-revalidate simply explicitly declare=
s
> that any reuse of previously cached documents must be revalidated with th=
e
> server. =A0There is no time that the document is fresh and does not need
> revalidation. =A0Without the Expires header, other browsers guess what we=
'd
> like them to (that the document isn't fresh) and IE 6's XmlHttpRequest us=
es
> heuristics and typically guesses that the document is fresh. =A0Adding an
> Expires header in the past (or a value of 0) is explicitly mentioned in t=
he
> HTTP RFC as the mechanism to mark as response as immediately stale. =A0I =
kept
> the date in the past (though I would have preferred sending a 0) since on=
e
> of the UUID tests was over-specified and would fail if it didn't have a
> valid date.

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.

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".

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 se=
e
> exactly what I would expect. =A0Second requests to unchanged documents ge=
t a
> 304 returned from the CouchDB and use the previously retrieved value on
> every browser I've tried. =A0Fire 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. :)

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.

>>
>> Note also that IE6 gets cache invalidation right when you don't go throu=
gh
>> XMLHttpRequest (that is, request CouchDB documents/views directly).
>>
>> A CouchDB-based application that runs on the client (CouchApp-style), an=
d
>> that needs to work on IE6, has the option to force all XHR requests to
>> invalidate the cache (for example by using jQuery's "cache=3Dfalse" opti=
on to
>> AJAX requests, which simply adds an extra timestamp-valued query string
>> parameter). In addition, it can choose to do so if, and only if, it dete=
cts
>> to be running on IE6. And of course, applications accessing CouchDB only
>> through server-side code do not need to care about this issue at all.
>>
>> Presumably we *could* add the browser detection and the conditional
>> addition of an Expires header to the CouchDB HTTP server, but browser
>> detection is a really slippery slope that I think we should avoid, and I=
E6
>> is likely (or so I hope) to be pretty much extinct by the time CouchDB
>> reaches the 1.0 mark. In any case, I'm -1 on any patch that does this
>> unconditionally, and -0.5 on any patch that does the Expires header danc=
e
>> conditionally. I'd be okay with adding the cache busting trick to Futon =
(but
>> again, only conditionally), and documenting the issue and workaround for
>> CouchApps.
>>
>> Cheers,
>
> The unconditional Expires header is the simplest fix. =A0As far as I can =
tell,
> it has no undesirable effects and accomplishes the goal. =A0If that doesn=
't go
> in, then I'd prefer to see the header values being configurable instead o=
f
> 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 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