Subject: Issues addressed by the -10 drafts

From: Mark Nottingham <[email-masked]>
Date: Thu, 22 Jul 2010 14:56:33 +0200

The editors believe that the following issues have been addressed by the -10 round of drafts. See <http://trac.tools.ietf.org/wg/httpbis/trac/report/15> for details; barring objections, they'll be closed soon.

non-specific (i.e., more than one part)
#143 - IANA registry for content/transfer encodings (editorial)

p1 Messaging
#73 - Clarification of the term "deflate"
#83 - OPTIONS * and proxies
#165 Case-senstivity of HTTP-date
#196 Term for the requested resource's URI (editorial)*
#200 use of term "word" when talking about header structure (editorial) 

p3 Payload
#155 Content Sniffing

p6 Caching
#29 Age Calculation
#168 Request and Response CC directive requirements (editorial)
#174 Caching Authenticated Responses
#211 Heuristic Caching of URLs with Query Components

* Note that some aspects of #196 were split into two new issues, #221 and #222.

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 22 Jul 2010 14:13:43 -0700

> #196 Term for the requested resource's URI (editorial)*

BTW, I have been trying to work with this phrase
(the Effective Request URI) in my edits and have found it
cumbersome and painful to read -- it tends to obscure
whatever else is in the same sentence.

Is there some reason we can't just call it the target URI?

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 Jul 2010 09:48:46 +0200

On 22.07.2010 23:13, Roy T. Fielding wrote:
> ...

I think we *can* call them "target URI". The reason we picked "Effective 
Request URI" is that we stole it from Jeff's STS spec, and I found the 
term made it clear that this is something that may need to be computed 
from various bits on the wire.

If we change it, of course STS should follow that change.

That being said, there are a few things left to do, no matter how we 
call it:

1) There's currently some overlap between 4.2 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#the.resource.identified.by.a.request> 
and 4.3 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#effective.request.uri>). 
Maybe that should be reduced?

2) Does eURI/target URI need to handle the case of HTTP/1.0 requests 
without Host header? 
(<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/221>)

3) Is the current strategy of handling the request-target of "*" the 
right one? (<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/222>)

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 23 Jul 2010 01:47:24 -0700

On Jul 23, 2010, at 12:48 AM, Julian Reschke wrote:

> I think we *can* call them "target URI". The reason we picked "Effective Request URI" is that we stole it from Jeff's STS spec, and I found the term made it clear that this is something that may need to be computed from various bits on the wire.
> 
> That being said, there are a few things left to do, no matter how we call it:
> 
> 1) There's currently some overlap between 4.2 (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#the.resource.identified.by.a.request> and 4.3 (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#effective.request.uri>). Maybe that should be reduced?

Yes, they should be merged, and 4.1 needs to be reorganized as well
to be more readable.

> 2) Does eURI/target URI need to handle the case of HTTP/1.0 requests without Host header? (<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/221>)

Yes, though we should be clear that HTTP/1.0 requests should also
have Host defined -- it just isn't required for legacy stuff.

> 3) Is the current strategy of handling the request-target of "*" the right one? (<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/222>)

I think so, though we should verify implementations before
last call.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 Jul 2010 16:26:31 +0200

On 22.07.2010 14:56, Mark Nottingham wrote:
> The editors believe that the following issues have been addressed by the -10 round of drafts. See<http://trac.tools.ietf.org/wg/httpbis/trac/report/15>  for details; barring objections, they'll be closed soon.
> ...

Hi,

we just figured out that an addition to P4 in -10 may allow us to close 
issue 39 as well:

2.1. Example: Entity Tags varying on Content-Negotiated Resources

    Consider a resource that is subject to content negotiation (Section 4
    of [Part3]), and where the representations returned upon a GET
    request vary based on the Accept-Encoding request header field
    (Section 5.3 of [Part3]):

    >> Request:

      GET /index HTTP/1.1
      Host: www.example.com
      Accept-Encoding: gzip

    In this case, the response may use the gzip Content Coding or not.
    If it does, it might look like that:

    >> Response:

      HTTP/1.1 200 OK
      Date: Thu, 26 Mar 2010 00:05:00 GMT
      ETag: "123-a"
      Content-Length: 70
      Vary: Accept-Encoding
      Content-Type: text/plain

      Hello World!
      Hello World!
      Hello World!
      Hello World!
      Hello World!

    A variant that does use gzip Content Coding would be:

    >> Response:

      HTTP/1.1 200 OK
      Date: Thu, 26 Mar 2010 00:05:00 GMT
      ETag: "123-b"
      Content-Length: 43
      Vary: Accept-Encoding
      Content-Type: text/plain
      Content-Encoding: gzip

      ...binary data...

       Note: Content Codings are a property of the response entity, thus
       affect the Entity Tag. An alternative are Transfer Codings
       (Section 6.2 of [Part1]) which apply only to the transfer of the
       message, and thus do not require assigning distinct entity tags.

(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p4-conditional-10.html#rfc.section.2.1>)

...this essentially adds the case people were confused about as an example.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 Jul 2010 17:25:17 +0200

Hi,

we just noticed that this was addressed with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/825>, which added 
registration requirements in Section 3.2.3, and the initial registry 
contents in Section 5.1.

Best regards, Julian