- From: Mike Meyer <mwm@contessa.phone.net>
- Date: Mon, 29 Jan 1996 12:51:14 PST
- 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 UTC