Subject: HTTPbis status

From: Mark Nottingham <[email-masked]>
Date: Fri, 6 Mar 2009 14:14:10 +1100

HTTPbis will be meeting at IETF74; draft agenda available at:
   http://www.ietf.org/proceedings/09mar/agenda/httpbis.txt

Note that we've provisionally left some time at the end of the meeting  
to discuss HTTP-related drafts that are not currently within the scope  
of HTTPbis (time permitting). If you have such a draft and would like  
to give a *brief* presentation on it, please contact me.

* HTTP Revision

We've had a quiet period in the last few months, but the editors have  
been working in the background; they expect to have the -06 generation  
of the HTTPbis drafts published before the meeting; they will  
incorporate more editorial changes (including the ABNF conversion) as  
well as several issue resolution proposals for consideration by the WG.

* Security Properties

The security properties document is currently expired. Although it is  
a chartered deliverable, there doesn't currently seem to be a will in  
the WG to complete it, and its editors believe that it is not  
currently complete.

The future of this document is one of the things that we'll discuss in  
San Francisco.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 06 Mar 2009 17:33:07 +0100

Mark Nottingham wrote:
> ...
> ...

The ABNF conversion 
(<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/36)> will be 
completed with the -06 drafts. The main changes were:

- removal of implied LWS, being substituted by BWS, OWS, and RWS 
(already in draft -05)

- use RFC5234 ABNF syntax, extended by list rule (see 
<http://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p1-messaging.html#rfc.section.1.2.1>)

- add appendices with collected, normalized and sorted ABNF (with list 
rules being expanded)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Mar 2009 11:07:02 +0100

> well as several issue resolution proposals for consideration by the WG.

These drafts have been submitted yesterday. They contain quite a number 
of substantive changes, plus major rewrites in Parts 1 (URIs, 
Connections, and Message Parsing) and 6 (Caching). All non-editorial 
changes should be mentioned in the "Changes Since ..." appendices; diffs 
are available from tools.ietf.org (linked from the HTMLized
versions) and from 
<http://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/diffs/>.

The top changes are:

- Many parts of Part 6 (Caching) have been rewritten from scratch,
   resulting in a more concise spec. There are several open issues and
   TODOs related to this change, so please carefully review this part in
   general, and also pay attention to the inlined comments.

- All the issues around the BNF format and implied LWS have been
   resolved, see <http://tools.ietf.org/wg/httpbis/trac/ticket/36> for
   details.

- In Part 1, the HTTP URL definition has been updated to be based on RFC
   3986, quite some text in the introductory chapters has been updated,
   and lots of URI related history (better summarized in RFC 3986) has
   been removed.

We think the issue below have been resolved with these drafts, and are
planning to close them soon:

- #30: "Header LWS" (<http://tools.ietf.org/wg/httpbis/trac/ticket/30>)
- #63: "RFC2047 encoded words" 
(<http://tools.ietf.org/wg/httpbis/trac/ticket/63>)
- #74: "Character Encodings in TEXT" 
(<http://tools.ietf.org/wg/httpbis/trac/ticket/74>)
- #77: "Line folding" (<http://tools.ietf.org/wg/httpbis/trac/ticket/77>)
- #83: "OPTIONS * and proxies" 
(<http://tools.ietf.org/wg/httpbis/trac/ticket/83>)
- #85: "Custom Ranges" (<http://tools.ietf.org/wg/httpbis/trac/ticket/85>)
- #111: "Use of TEXT" (<http://tools.ietf.org/wg/httpbis/trac/ticket/111>)

Best regards, Julian

---

From: Dan Winship <[email-masked]>
Date: Wed, 11 Mar 2009 11:40:18 -0400

You need to s/Request-URI/request-target/ globally.

2.1. Response Cacheability

The new text, with the split between what can be cached and what can be
returned, is MUCH clearer (and more correct) than the old. But I think
the cacheability section would be even clearer if you negated the sense
of the list, and/or split out the special shared cache rules:

   A cache MUST NOT store a response to any request if:

   o  the request method is not defined as being cacheable, or

   o  the "no-store" cache directive (see Section 3.2) appears
      in request or response headers, or

   o  the response is partial or incomplete, if the cache does not
      understand partial responses (see Section 2.1.1).

   Additionally, a shared cache MUST NOT store a response if:

   o  the "private" cache response directive (see Section 3.2)
      appears in the response, or

   o  the "Authorization" header (see Section 3.1 of [Part7])
      appears in the request, and the "public" directive is not
      present (see Section 3.2).

   A cache MAY store a response to any other request.

(If you don't take this patch, note that there's a missing ")" in the
third item in the original.)

2.1.1. Storing Partial and Incomplete Responses

>  A cache that does not support the Range and Content-Range headers	
>  MUST NOT store incomplete or partial responses.

FWIW, this is now redundant with 2.1.

2.2. Constructing Responses from Caches

>  o  selecting request-headers nominated by the stored response (if
>     any) match those presented (see Section 2.6), and

"selecting request-headers" haven't been mentioned yet, so "selecting"
looks like it's a verb not an adjective and then the sentence doesn't
parse. We mostly just need to call out to Section 2.6 here anyway. Maybe:

   o  request-headers used for content negotiation match between the
      stored response and the presented request (see Section 2.6), and

>  o  the presented request and stored response are free from directives
>     that would prevent its use (see Section 3.2 and Section 3.4), and

s/its/the response's/

2.3.1.1. Calculating Heuristic Freshness

>  Heuristics MUST NOT be used for other response status codes.

It is not possible to define heuristic freshness for new status codes?

2.3.2. Calculating Age

The rules don't say what date_value is for a response with no Date
header. Part 1, 8.3 says that "A received message that does not have a
Date header field MUST be assigned one by the recipient if the message
will be cached by that recipient", but doesn't say what that value
should be. Given the rules here, I suspect it should add a Date header
with request_time, to make the worst-case assumption about its age?

Likewise, the rules don't say what age_value is when the response has
no Age header. In this case, it probably shouldn't even do the steps
of the calculation involving age_value...

The detailed description of the Age computation uses "now" twice where
it means "response_time":

>       corrected_received_age = max(now - date_value, age_value)

>       corrected_initial_age = corrected_received_age
>                             + (now - request_time)

("now" is the time when the response is being served to a client, as
opposed to "response_time", which is when it was received from the
server.) The summary at the end uses "response_time" correctly.

Even after fixing that, the math still seems wrong, because there's no
reason to worry about "response_delay" if you're using the
"response_time - date_value" case for corrected_received_age. (Unless
you're worried about clock skew, but in that case it's still adding
response_delay in the wrong place.)

I think the correct calculation for corrected_initial_age is something
like:

    response_delay = response_time - request_time;

    if (response_time > date_value)
        apparent_age = response_time - date_value;
    else /* clock skew! */
        apparent_age = response_delay;

    if (is_first_hand_response)
        corrected_initial_age = apparent_age;
    else {
        corrected_age_value = age_value + response_delay;
        corrected_initial_age = max(apparent_age, corrected_age_value);
    }

or maybe

    apparent_age = max(response_time - date_value, response_delay);

if you want to assume clock skew is more likely than very-new responses.

2.3.3. Serving Stale Responses

>  Caches SHOULD NOT return stale responses unless they are disconnected	
>  (i.e., it cannot contact the origin server or otherwise find a

s/it cannot/they cannot/

2.5. Request Methods that Invalidate

>  The following HTTP methods MUST cause a cache to invalidate the	
>  Request-URI as well as the Location and Content-Location headers (if	
>  present):

Part 3, 5.7 says "The meaning of the Content-Location header in PUT or
POST requests is undefined; servers are free to ignore it in those
cases", so presumably the rule here only applies to Content-Location in
the response headers?

3.2.2. Response Cache-Control Directives

The discussion of optional field-names in "private" and "no-cache" is
vague about whether the cache MAY or MUST revalidate when handling a
subsequent request for that resource. That is, if another request for
the resource comes in, and the cached response is still fresh, is the
cache allowed to return it, minus the forbidden headers, or is it
required to revalidate, and merge in new values of those headers from
the 304 response?)

Under no-cache:

>     This allows an origin server to prevent caching even by caches
>     that have been configured to return stale responses.

That describes must-revalidate. no-cache is stronger than that. Maybe:

      Essentially, a response returned with this directive is never
      fresh, and is never allowed to be served stale.

>     names, this requirement is limited to the field-values assosicated

s/assosicated/associated/

-- Dan