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

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 <slink@schokola.de> 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:
> 
> 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
> 

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

Received on Monday, 22 October 2012 23:09:34 UTC