W3C home > Mailing lists > Public > www-talk@w3.org > January to February 1996

Re: SERVER_PROTOCOL ? ( was Re: Microsoft IE ... )

From: Mike Meyer <mwm@contessa.phone.net>
Date: Mon, 29 Jan 1996 12:51:14 PST
Message-Id: <19960129.75FFF40.B798@contessa.phone.net>
To: www-talk@w3.org
> What I have thought that might be a different solution would be the use of
> SERVER_PROTOCOL.  Right now it always returns HTTP/1.0 which isn't really
> that useful.  I think I saw in the spec that you can tack on an HTTP
> extension version to the end of the HTTP/1.0.  Wouldn't it be useful if
> browsers sent HTTP/1.0/1.0 if they support HTML version 1.0 and HTTP/1.0/2.0
> if they supported HTML version 2.0?

SERVER_PROTOCOL isn't always HTTP/1.0 - it's just that most of the
time. It can also be HTTP/0.9 (or not set?). Your nph scripts should
check SERVER_PROTOCOL to see if the client expects header information
back, and only send it if they do.

Besides, the Accept: mechanism that was in the early HTTP 1.0 drafts
did pretty much what you are asking for. Some servers can already deal
with this. Some clients sent Accept headers that included version
information.

> Yes, this doesn't solve everything
> given the Netscape extensions, but at least we would know which HTML
> standard the browser can support.

The problem with using Accept: is that most clients use "text/html" in
the Accept: headers to mean "Anything that looks vaguely like HTML".

The problem with this level of solution is that the people doing
content negotiation at this level specifically want to deal with the
proprietary extensions. If you are willing to write HTML that is
viewable in all browsers, dealing with HTML 1.0 vs HTML 2.0 isn't
noticably harder than dealing with NHTML. So a solution - whether
stopgap or permanent - has to be able to deal with proprietary
extensions.

	<mike
Received on Monday, 29 January 1996 15:58:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:19 GMT