W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2007

RE: HTTP idea

From: Joris Dobbelsteen <Joris@familiedobbelsteen.nl>
Date: Thu, 11 Jan 2007 10:46:42 +0100
Message-ID: <73427AD314CC364C8DF0FFF9C4D693FF54E6@nehemiah.joris2k.local>
To: "Nicholas Shanks" <contact@nickshanks.com>
Cc: <ietf-http-wg@w3.org>

>-----Original Message-----
>From: ietf-http-wg-request@w3.org 
>[mailto:ietf-http-wg-request@w3.org] On Behalf Of Nicholas Shanks
>Sent: donderdag 11 januari 2007 3:47
>To: ietf-http-wg@w3.org
>Subject: HTTP idea
>I just wanted to bounce this idea around to the folks on this list:
>It would be nice if UAs had a way of giving a webserver a GUID 
>to identify themselves,

This is privacy sensitive. (Such option is in Windows Media Player and
it's one of the first I disable).
Furthermore, you can use cookies to establish a session and identify the

> along with a list of accepted media 
>types. That list could then be checked against for every 
>request on a keep-alive connection, without the UA having to 
>repeatedly send huge Accept* headers.

No, this cannot be done: HTTP is stateless.
And being stateless has major advantages, just like IP is stateless too.
This means a request (or packet for IP) can be send via any path to its
destination. Furthermore, multiple requests can be multiplexed onto a
single path. The latter is frequently done by HTTP proxies.

>Then if, say, a new plug-in was installed, or the language 
>changed, they could send the same GUID and an updated Accept* 
>header to replace the old one, and new negotiated content 
>would be received with the next request.

This would require servers to store an extremely large number of GUID
and configuration settings, including the clients to do bookkeeping.
This is rather impractical (take a good site microsoft.com and estimate
the number of visitors and guess the storage costs).

>The problem I'm trying to solve is one of increasingly large 
>Accept headers as UAs become more sophisticated. Current 
>practice is to append an asterisk to the end of the list, in 
>effect saying "I will accept any format that could ever get 
>invented" despite obviously not being able to handle future formats.
>We have already seen this with new image formats.
>And we could shave off another two unnecessary response 
>headers from the bulk of pages by defining default values for 
>Content-Script-Type and Content-Style-Type. I presume this has 
>been brought up before, but a search of the archives for both 
>header names returned no results. May I ask why this was not 
>done in HTTP/1.1 ?

As far as I know these headers are not part of the HTTP specification.

Please read the specification more closely.

Hope this helps

- Joris
Received on Thursday, 11 January 2007 10:08:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:41 UTC