Subject: WGLC issue: (minor?) scope of client/server attributes (specifically: downgrades) in p1

From: Nils Goroll <[email-masked]>
Date: Thu, 18 Oct 2012 15:55:28 +0200

Hi,

reviewing the draft due to the last call, I noticed an aspect which probably is 
of minor importance, but I don't want to miss the chance to seek some clarification:

On this example, but not necessarily limited to it:

				--- 8< ---
2.6. Protocol Versioning
[...]
    An HTTP client MAY send a lower request version if it is known that
    the server incorrectly implements the HTTP specification, but only
    after the client has attempted at least one normal request and
    determined from the response status or header fields (e.g., Server)
    that the server improperly handles higher request versions.

				--- 8< ---

In this case, a client would cache a certain server attribute (here: HTTP 
version) for reuse in subsequent requests.

Should the standard define the scope of such attribute caching/reuse? Regarding 
the example above, should the client send a lower version
- for the next request to the same resource only
- for the next request
- for the duration of this connection or
- for all future connections to the same (fqdn|network address)/port?

The same question would probably apply to servers and intermediaries. In 
general, how are "a client" and "a server" defined with respect to caching of 
such attributes?

Thanks, Nils

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Oct 2012 10:09:09 +1100

Hi Nils,

Thanks for the feedback. It's an interesting question.

There are a few different things that implementations need to know along these lines, in practice, to operate efficiently. 

However, we generally try not to define / require things unless they're needed for interoperability. I.e., if two different clients cache this information using two different heuristics, the Web will still work. 

On the other hand, if we specify a particular algorithm, that ties the hands of implementers so that they can't experiment with different approaches here.

Cheers,

On 19/10/2012, at 12:55 AM, Nils Goroll <[email-masked]> wrote:

> Hi,
> 
> reviewing the draft due to the last call, I noticed an aspect which probably is of minor importance, but I don't want to miss the chance to seek some clarification:
> 
> In this case, a client would cache a certain server attribute (here: HTTP version) for reuse in subsequent requests.
> 
> Should the standard define the scope of such attribute caching/reuse? Regarding the example above, should the client send a lower version
> The same question would probably apply to servers and intermediaries. In general, how are "a client" and "a server" defined with respect to caching of such attributes?
> 
> Thanks, Nils
> 

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

---

From: Nils Goroll <[email-masked]>
Date: Tue, 23 Oct 2012 22:24:02 +0200

Hi Mark,

On 10/23/12 01:09 AM, Mark Nottingham wrote:
> we generally try not to define / require things unless they're needed for interoperability

So shouldn't the scope for downgrades be defined for interoperability?

For upgrades, the draft defines the scope to be the connection, and it appears 
to me that this would be a sensible scope also for downgrades.

Nils

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Oct 2012 15:59:50 +1100

On 24/10/2012, at 7:24 AM, Nils Goroll <[email-masked]> wrote:

> For upgrades, the draft defines the scope to be the connection, and it appears to me that this would be a sensible scope also for downgrades.

A UA might decide to "remember" the downgrade longer than the scope of a single connection.

Cheers,

---

From: Nils Goroll <[email-masked]>
Date: Wed, 24 Oct 2012 13:20:05 +0200

> A UA might decide to "remember" the downgrade longer than the scope of a single connection.

Then the implication would be that all actual server processes behind an address 
or fqdn had to support the same version(s).

Also, this would not be consistent with the definition for upgrades, which I'd 
find confusion.

Thanks, Nils

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 25 Oct 2012 10:56:39 +1100

On 24/10/2012, at 10:20 PM, Nils Goroll <[email-masked]> wrote:

> Then the implication would be that all actual server processes behind an address or fqdn had to support the same version(s).

No - HTTP/1.0 is backwards-compatible with 1.1. There is not interoperability problem, because it still works.

---

From: Nils Goroll <[email-masked]>
Date: Thu, 25 Oct 2012 12:49:59 +0200

Hi Mark,

> No - HTTP/1.0 is backwards-compatible with 1.1. There is not interoperability problem, because it still works.

sorry, now you've lost me. The whole point of the downgrades is corner case 
handling, iiuc.

At any rate, I don't have any personal interest in this topic, so I'm fine with 
leaving it as it is. But I still believe that it would be a good idea to define 
the scope for downgrades as for upgrades.

Thank you, Nils