If-None-Match and IMS (new Issue IMS_INM_MISMATCH)

Jim Gettys (jg@pa.dec.com)
Tue, 11 Nov 1997 12:58:38 -0800


This is a multi-part message in MIME format, created by Pachyderm.
The parts are separated by "--1" lines.
The first part is a covering note, the others are attachments.

--1
Content-type: text/plain

This documents discussions on the implementation list that shows
a new protocol issue (IMS_INM_MISMATCH).

Now added to the issues list.
				- Jim Gettys


--1
Content-type: message/rfc822

Received: by src-mail.pa.dec.com; id AA06029; Wed, 5 Nov 97 16:44:08 -0800
Received: by pobox1.pa.dec.com; id AA12854; Wed, 5 Nov 97 16:44:13 -0800
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by mail2.digital.com (8.7.5/UNX 1.5/1.0/WV) with ESMTP id QAA03533
	for <jg@pa.dec.com>; Wed, 5 Nov 1997 16:37:38 -0800 (PST)
Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id TAA15643; Wed, 5 Nov 1997 19:34:16 -0500 (EST)
Received: by www19.w3.org (8.8.5/8.6.12) id TAA14918; Wed, 5 Nov 1997 19:26:40 -0500 (EST)
Resent-Date: Wed, 5 Nov 1997 19:26:40 -0500 (EST)
Resent-Message-Id: <199711060026.TAA14918@www19.w3.org>
X-Authentication-Warning: www10.w3.org: Host doggate.microsoft.com [131.107.2.63] claimed to be doggate.exchange.microsoft.com
Message-Id: <2FBF98FC7852CF11912A00000000000107196961@DINO>
From: "Henry Sanders (Exchange)" <henrysa@EXCHANGE.MICROSOFT.com>
To: w3c-http@w3.org
Date: Wed, 5 Nov 1997 16:26:22 -0800 
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.0)
Content-Type: text/plain
Subject: If-None-Match and IMS
Resent-From: w3c-http@w3.org
X-Mailing-List: <w3c-http@w3.org> archive/latest/125
X-Loop: w3c-http@w3.org
Sender: w3c-http-request@w3.org
Resent-Sender: w3c-http-request@w3.org
Precedence: list
X-UIDL: ee61933cd056c7419731d115eb834bf0

Is there a consensus on the correct behavior for a server when it
receives a request with conflicting If-None-Match and If-Modified-Since
headers, for instance where the I-N-M ETag is outdated but the I-M-S
date is good?

For example, take the following sequence

GET /foo.txt HTTP/1.1
Host: server.company.com

HTTP/1.1 200 OK
Last-Modified: Wed, 05 Nov 1997 22:10:48 GMT
ETag: "12345"
Content-Length: ...

<data>

GET /foo.txt HTTP/1.1
Host: server.company.com
If-None-Match: "12344"
If-Modified-Since: Wed, 05 Nov 1997 22:10:48 GMT

Assuming the Last-Modified date hasn't changed, what should the server
send back as a response to the 2nd request, 304 or 200? I would have
thought 200 is correct, since the ETag is invalid or out of date.
However the spec indicates that the I-N-M header is to be treated as if
it isn't present if the ETag doesn't match, and then the I-M-S would
lead to a 304 response. Also the paragraph about I-N-M being ignored if
the request would otherwise generate a non-2xx response would indicate
that a 304 is correct. But there would seem to be a window here, where
/foo.txt is modified twice in less than a second, the ETag is updated
but the L-M date isn't, and a client using an out of date ETag gets a
304 anyway. Or am I missing something here?

Henry



--1
Content-type: message/rfc822

Received: by src-mail.pa.dec.com; id AA08338; Tue, 11 Nov 97 08:33:06 -0800
Received: by pobox1.pa.dec.com; id AA00440; Tue, 11 Nov 97 08:33:10 -0800
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by mail1.digital.com (8.7.5/UNX 1.5/1.0/WV) with ESMTP id IAA27952
	for <jg@pa.dec.com>; Tue, 11 Nov 1997 08:27:16 -0800 (PST)
Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id LAA13996; Tue, 11 Nov 1997 11:23:54 -0500 (EST)
Received: by www19.w3.org (8.8.5/8.6.12) id LAA07535; Tue, 11 Nov 1997 11:13:38 -0500 (EST)
Resent-Date: Tue, 11 Nov 1997 11:13:38 -0500 (EST)
Resent-Message-Id: <199711111613.LAA07535@www19.w3.org>
To: "Henry Sanders (Exchange)" <henrysa@exchange.microsoft.com>
Cc: w3c-http@w3.org
In-Reply-To: Your message of "Wed, 05 Nov 1997 16:26:22 PST."
             <2FBF98FC7852CF11912A00000000000107196961@DINO> 
Date: Tue, 11 Nov 1997 07:56:17 -0800
From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-Id:  <9711110807.aa04829@paris.ics.uci.edu>
Subject: Re: If-None-Match and IMS 
Resent-From: w3c-http@w3.org
X-Mailing-List: <w3c-http@w3.org> archive/latest/129
X-Loop: w3c-http@w3.org
Sender: w3c-http-request@w3.org
Resent-Sender: w3c-http-request@w3.org
Precedence: list
X-UIDL: 714ff5a751b7566658430d46463ba942

Henry Sanders writes:
>Is there a consensus on the correct behavior for a server when it
>receives a request with conflicting If-None-Match and If-Modified-Since
>headers, for instance where the I-N-M ETag is outdated but the I-M-S
>date is good?

Hmmm, I don't know about consensus, but I implemented it using the
principle that an ETag test always overrides IMS.  I mentioned it as
an issue on http-wg a long time ago, since the RFC fails to specify
the ordering.  The Apache code (and comments) are below.

>For example, take the following sequence
>
>GET /foo.txt HTTP/1.1
>Host: server.company.com
>
>HTTP/1.1 200 OK
>Last-Modified: Wed, 05 Nov 1997 22:10:48 GMT
>ETag: "12345"
>Content-Length: ...
>
><data>
>
>GET /foo.txt HTTP/1.1
>Host: server.company.com
>If-None-Match: "12344"
>If-Modified-Since: Wed, 05 Nov 1997 22:10:48 GMT
>
>Assuming the Last-Modified date hasn't changed, what should the server
>send back as a response to the 2nd request, 304 or 200?

200.

>I would have
>thought 200 is correct, since the ETag is invalid or out of date.
>However the spec indicates that the I-N-M header is to be treated as if
>it isn't present if the ETag doesn't match, and then the I-M-S would
>lead to a 304 response. Also the paragraph about I-N-M being ignored if
>the request would otherwise generate a non-2xx response would indicate
>that a 304 is correct. But there would seem to be a window here, where
>/foo.txt is modified twice in less than a second, the ETag is updated
>but the L-M date isn't, and a client using an out of date ETag gets a
>304 anyway. Or am I missing something here?

Nope, that about sums it up.  200 is what the response should be, but
the RFC is less than clear.

....Roy
=====================================================================

API_EXPORT(int) meets_conditions(request_rec *r)
{
    char *etag = table_get(r->headers_out, "ETag");
    char *if_match, *if_modified_since, *if_unmodified, *if_nonematch;
    time_t mtime;

    /* Check for conditional requests --- note that we only want to do
     * this if we are successful so far and we are not processing a
     * subrequest or an ErrorDocument.
     *
     * The order of the checks is important, since ETag checks are supposed
     * to be more accurate than checks relative to the modification time.
     * However, not all documents are guaranteed to *have* ETags, and some
     * might have Last-Modified values w/o ETags, so this gets a little
     * complicated.
     */

    if (!is_HTTP_SUCCESS(r->status) || r->no_local_copy) {
        return OK;
    }

    mtime = (r->mtime != 0) ? r->mtime : time(NULL);

    /* If an If-Match request-header field was given
     * AND if our ETag does not match any of the entity tags in that field
     * AND the field value is not "*" (meaning match anything), then
     *     respond with a status of 412 (Precondition Failed).
     */
    if ((if_match = table_get(r->headers_in, "If-Match")) != NULL) {
        if ((etag == NULL) ||
            ((if_match[0] != '*') && !find_token(r->pool, if_match, etag))) {
            return HTTP_PRECONDITION_FAILED;
        }
    }
    else {
        /* Else if a valid If-Unmodified-Since request-header field was given
         * AND the requested resource has been modified since the time
         * specified in this field, then the server MUST
         *     respond with a status of 412 (Precondition Failed).
         */
        if_unmodified = table_get(r->headers_in, "If-Unmodified-Since");
        if (if_unmodified != NULL) {
            time_t ius = parseHTTPdate(if_unmodified);

            if ((ius != BAD_DATE) && (mtime > ius)) {
                return HTTP_PRECONDITION_FAILED;
            }
        }
    }

    /* If an If-None-Match request-header field was given
     * AND if our ETag matches any of the entity tags in that field
     * OR if the field value is "*" (meaning match anything), then
     *    if the request method was GET or HEAD, the server SHOULD
     *       respond with a 304 (Not Modified) response.
     *    For all other request methods, the server MUST
     *       respond with a status of 412 (Precondition Failed).
     */
    if_nonematch = table_get(r->headers_in, "If-None-Match");
    if (if_nonematch != NULL) {
        int rstatus;

        if ((if_nonematch[0] == '*')
            || ((etag != NULL) && find_token(r->pool, if_nonematch, etag))) {
            rstatus = (r->method_number == M_GET) ? HTTP_NOT_MODIFIED
                                                  : HTTP_PRECONDITION_FAILED;
            return rstatus;
        }
    }
    /* Else if a valid If-Modified-Since request-header field was given
     * AND it is a GET or HEAD request
     * AND the requested resource has not been modified since the time
     * specified in this field, then the server MUST
     *    respond with a status of 304 (Not Modified).
     * A date later than the server's current request time is invalid.
     */
    else if ((r->method_number == M_GET)
             && ((if_modified_since =
                  table_get(r->headers_in, "If-Modified-Since")) != NULL)) {
        time_t ims = parseHTTPdate(if_modified_since);

        if ((ims >= mtime) && (ims <= r->request_time)) {
            return HTTP_NOT_MODIFIED;
        }
    }
    return OK;
}



--1
Content-type: message/rfc822

Received: by src-mail.pa.dec.com; id AA12333; Tue, 11 Nov 97 10:10:46 -0800
Received: by pobox1.pa.dec.com; id AA04323; Tue, 11 Nov 97 10:10:51 -0800
Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63])
	by mail1.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id KAA32563
	for <jg@pa.dec.com>; Tue, 11 Nov 1997 10:05:29 -0800 (PST)
Received: by DOGGATE with Internet Mail Service (5.5.1960.3)
	id <W48CDCFQ>; Tue, 11 Nov 1997 10:05:01 -0800
Message-Id: <2FBF98FC7852CF11912A00000000000107196985@DINO>
From: "Henry Sanders (Exchange)" <henrysa@EXCHANGE.MICROSOFT.com>
To: "'jg@pa.dec.com'" <jg@PA.DEC.COM>,
        "'Larry Masinter'"
	 <masinter@parc.xerox.com>
Subject: FW: If-None-Match and IMS
Date: Tue, 11 Nov 1997 10:04:50 -0800
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
X-UIDL: 2e6e770f46c5739ff87ebb340650644f

Just what you wanted to see, another HTTP/1.1 issue....

This is something I sent out to the HTTP implementors list about a week
ago. Looks like the spec says to send a 304 when a 200 response would be
better. Any comments?

Henry

> -----Original Message-----
> From:	Henry Sanders (Exchange) 
> Sent:	Wednesday, November 05, 1997 4:26 PM
> To:	w3c-http@w3.org
> Subject:	If-None-Match and IMS
> 
> Is there a consensus on the correct behavior for a server when it
> receives a request with conflicting If-None-Match and
> If-Modified-Since headers, for instance where the I-N-M ETag is
> outdated but the I-M-S date is good?
> 
> For example, take the following sequence
> 
> GET /foo.txt HTTP/1.1
> Host: server.company.com
> 
> HTTP/1.1 200 OK
> Last-Modified: Wed, 05 Nov 1997 22:10:48 GMT
> ETag: "12345"
> Content-Length: ...
> 
> <data>
> 
> GET /foo.txt HTTP/1.1
> Host: server.company.com
> If-None-Match: "12344"
> If-Modified-Since: Wed, 05 Nov 1997 22:10:48 GMT
> 
> Assuming the Last-Modified date hasn't changed, what should the server
> send back as a response to the 2nd request, 304 or 200? I would have
> thought 200 is correct, since the ETag is invalid or out of date.
> However the spec indicates that the I-N-M header is to be treated as
> if it isn't present if the ETag doesn't match, and then the I-M-S
> would lead to a 304 response. Also the paragraph about I-N-M being
> ignored if the request would otherwise generate a non-2xx response
> would indicate that a 304 is correct. But there would seem to be a
> window here, where /foo.txt is modified twice in less than a second,
> the ETag is updated but the L-M date isn't, and a client using an out
> of date ETag gets a 304 anyway. Or am I missing something here?
> 
> Henry
> 


--1
Content-type: message/rfc822

Received: by src-mail.pa.dec.com; id AA12703; Tue, 11 Nov 97 10:19:07 -0800
Received: by pobox1.pa.dec.com; id AA04634; Tue, 11 Nov 97 10:19:13 -0800
Received: from www10.w3.org (www10.w3.org [18.23.0.20])
	by mail2.digital.com (8.7.5/UNX 1.5/1.0/WV) with ESMTP id KAA14655
	for <jg@pa.dec.com>; Tue, 11 Nov 1997 10:12:52 -0800 (PST)
Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id NAA14466; Tue, 11 Nov 1997 13:09:29 -0500 (EST)
Received: by www19.w3.org (8.8.5/8.6.12) id NAA08780; Tue, 11 Nov 1997 13:00:50 -0500 (EST)
Resent-Date: Tue, 11 Nov 1997 13:00:50 -0500 (EST)
Resent-Message-Id: <199711111800.NAA08780@www19.w3.org>
X-Authentication-Warning: www10.w3.org: Host doggate.microsoft.com [131.107.2.63] claimed to be doggate.exchange.microsoft.com
Message-Id: <2FBF98FC7852CF11912A00000000000107196984@DINO>
From: "Henry Sanders (Exchange)" <henrysa@exchange.microsoft.com>
To: "'Roy T. Fielding'" <fielding@kiwi.ics.uci.edu>
Cc: w3c-http@w3.org
Date: Tue, 11 Nov 1997 10:00:12 -0800
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Subject: RE: If-None-Match and IMS 
Resent-From: w3c-http@w3.org
X-Mailing-List: <w3c-http@w3.org> archive/latest/130
X-Loop: w3c-http@w3.org
Sender: w3c-http-request@w3.org
Resent-Sender: w3c-http-request@w3.org
Precedence: list
X-UIDL: 3450b150570557cab992927cb3f47e19

> >that a 304 is correct. But there would seem to be a window here,
> where
> >/foo.txt is modified twice in less than a second, the ETag is updated
> >but the L-M date isn't, and a client using an out of date ETag gets a
> >304 anyway. Or am I missing something here?
> 
> Nope, that about sums it up.  200 is what the response should be, but
> the RFC is less than clear.
> 
	I agree that 200 is what the response should be, but saying the
RFC is unclear is an understatement. I think the RFC actually
contradicts this view, twice. I'll pass this on to the HTTP group, maybe
we can get it fixed in the update.

	Henry




--1--