Re: Server response version number

At 09:09 PM 10/20/96 PDT, Larry Masinter wrote:
>> 1) A client always sends a request using the latest version it supports.
>> Only if the client already knows the version of the server and this version
>> is inferrior to the version of the client, then it should downgrade to a
>> version understood by the server.
>
>Why bother downgrading? MAY downgrade, not SHOULD downgrade.

This was meant as a practical advice and some existing 1.0 server
applications break or act confused if you send them an HTTP/1.1 request.
Therefore it was more of a "if you want to be on the safe side" should than
targeted directly towards the specification. I actually don't think this
belongs in the spec except from the part already being there in section 19.7.

>> 2) A server always responds with the same version as the request. Only if
>> this version is not directly supported by the server, it should take the
>> version that comes closest. If the semantics of the response requires a
>> specific version and this is not the version of the client then it should
>> return "505 HTTP Version not supported".
>
>You say "always" in the first sentence and then give conditions when
>it doesn't hold in the second. That's confusing.

No, it's just another way or arguing which I thought was used frequently.

	a) First you give the general case
	b) Then you give all the exceptions

>Perhaps you mean to say that a server SHOULD respond with the same
>version as the request?

Only if it is capable of doing so. Otherwise not. I actually believe this
is close to what Jeff points out in his (later) mail.

OK - no more on versions from my side!

>On a related issue, I'm concerned about the possibility that a single
>server might 'downgrade' depending on the URL rather than the version
>of the requestor: I think there are clients that presume the version
>of subsequent responses based on the version of previous responses.
>(The problem are CGI-generated headers, and the possibility of
>shortcutting header-rewriting.) I think the issue of 'downgrading'
>should explicitly prohibit this behavior.

I don't follow you on this one: "'downgrade' depending on the URL"?

There are most certainly clients that remember the version of a HTTP
server. This is for example part of libwww 5.0. The reason is that this if
you know that this the server is a HTTP/1.1 then you can do pipelining
immediately after you have opended a new connection. You don't have to wait
until the first response comes back.

This brings up another problem that I am not sure how to go about. Let's
say that we (the client) want to use pipelining as much as we can to all
HTTP/1.1 servers. Now, first time we talk to a server, we do not know the
version so we send a HTTP/1.1 request but don't do any pipelining. If it is
a HTTP/1.1 server and it keeps the connection open then we immediately
start sending x new requests down the pipe.

We then pause for 20 seconds before we are asked to issue 15 new requests
to the same host. Exactly at that same time, the server times out the
connection and sends a FIN. This packet has not reached us yet so we start
sending the 15 requests and everything is fine.

Depending on timing and how much we wrote we may either get the FIN or a
broken pipe on either the read or write. I have the feeling that this also
depends on the TCP stack but I am not sure.

This can (and should) all be dealt with but the remaining problem is
whether we can open a new connection and do pipelining immediately or we'll
have to wait for the first response before doing pipelining again. The
source of the problem is that we don't know _why_ the connection was
closed: Was it because of timeout, or because of overload or something
else. If we allow pipelining immediately upon opening a new connection
(which I strongly would prefer) then we assume that the connection was
closed due to a timeout. That may be OK, but I am not sure. If not then we
need a mechanism for the server to say why it closed the connection.

Does this story make sense at all?

Thanks,

Henrik

--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA

Received on Monday, 21 October 1996 12:41:52 UTC