Re: HTTP version number

Roy T. Fielding:
>Koen writes:
>> draft-kristol-http-state-mgmt-00 is not orthogonal to the HTTP version
>> number: see section 10.  Servers need the version number to know
>> whether they should send an old Netscape format Set-Cookie header or a
>> new HTTP/1.1 Set-Cookie header.
>This won't work.  For example
>     1.0 UA ---------> 1.1 Proxy ---------> 1.0 Origin Server
>will result in a 1.1 cookie being sent to a 1.0 user agent.

Isn't the 1.1 proxy required to convert the 1.1 response from the
server to a 1.0 response before sending it to the user agent?  This
conversion would presumably also convert the 1.1 cookie in the
Set-Cookie header to a 1.0 cookie.  At least this is how I read
Section 3.1 of the draft 1.1 spec.

You can argue that cookie conversion is too big a requirement to make
on proxies, especially because the Netscape cookie format is not
`official 1.0'.  In fact, I'm wondering about this myself.  We will
probably at least have to change state management draft to ensure that
conversion is more easy that it is now.

Anyway, conversion would only affect 1.1 set-cookie headers which have
max-age fields, these fields will need to be translated to expires
fields to get Netscape (1.0) format cookies.

A more general remark: I have been putting off thinking through
1.0<->1.1 interoperability problems for some time now.  I do not want
to rule out the possibility that the new 1.1 mechanisms that will be
introduced (hopefully) this month, combined with the current Section
3.1, will place so much subtle conversion requirements on proxy caches
that we will only ever see non-conforming 1.1 proxy caches.

My plan is to start worrying about this in April.

>The only features of HTTP that can depend on a minor version number
>change are those that are interpreted by neighbors in the communication.

I'm not sure what you means by this; I hope you don't mean "when
passing on a 1.1 response to a 1.0 client, a proxy may convert the 1.1
response to a 1.0 response by rewriting the version number in the
response status line".

> ...Roy T. Fielding


Received on Sunday, 3 March 1996 14:45:28 UTC