Subject: HTTP idea

From: Nicholas Shanks <[email-masked]>
Date: Thu, 11 Jan 2007 02:47:18 +0000

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, 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.

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.

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 ?

- Nicholas.

---

From: Jamie Lokier <[email-masked]>
Date: Thu, 11 Jan 2007 13:45:25 +0000

> replace the old one, and new negotiated content would be received  

That wouldn't work because requests can be reordered in the network,
either because they are on different TCP/IP connections, or because of
an intermediate proxy.

The UA would to generate a _new_ GUID whenever such a change occurs,
and send that with all new requests.

> results. May I ask why this was not done in HTTP/1.1 ?

Does anyone actually use those headers?  I've never seen them.

-- Jamie

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 11 Jan 2007 08:19:46 -0800

I don't know if we might want to say more about the practical
limitations of using accept: headers in HTTP, but see:
 
http://www.alvestrand.no/pipermail/ietf-types/2006-April/001707.html

and the follow-up discussion, including

http://www.alvestrand.no/pipermail/ietf-types/2006-April/001722.html

Larry

---

From: David Morris <[email-masked]>
Date: Thu, 11 Jan 2007 09:37:00 -0800 (PST)

First, I would note that in general, HTTP headers are such a small
percentage of the HTTP bytes transfered that the potential ROI is likely
discourage either design effort and subsequent adoption. But if reduction
of HTTP headers were desirable, a general mechanism which provided for
collaborative caching of selected headers in the context of a persistent
connection would be more useful than focus on accept headers. Something
like:
   Please remember this list of headers and values under this name as
   I expect to use the same values multiple times on this connection.

Then a request (or response) could reference previous headers as a set.
Lot of details would need to be worked out ranging from how to recognize
when a server (client) supports header caching, possible over-ride of
specific cached values, etc.

Another potential alternative would be to revisit some variation of a
binary protocol such as was being investigated as http-ng.

Finally, I would observe that without serious attention to more efficient
representation of content, there is really nothing we can do at the
protocol level efficient representation wise that will not be totally
eclipsed by the raw size of the textual representation of the page as the
move continues to richer interaction models.

OTOH ... some of the evolving uses of HTTP requests to obtain small bits
of data to be filled in by client side logic, validate single fields,
etc., might run much faster with terser HTTP requests ... but then even
much of that value would be achieved by having browsers aware of
programatic interactions and optimizing the headers actually needed. But
in that case, using XML to encode those requests might still negate any
advantage of smaller protocols.

Bottom line ... a lot of thought should be given to ROI and adoption
issues before spending much effort defining more efficient protocols.

Dave Morris

---

From: Nicholas Shanks <[email-masked]>
Date: Thu, 11 Jan 2007 21:34:20 +0000

> advantage of smaller protocols.

Wouldn't large sites encode their traffic with gzip (or alternative)  
before sending?

- Nicholas.

---

From: "Mike Dierken" <[email-masked]>
Date: Thu, 11 Jan 2007 17:05:48 -0800

> Wouldn't large sites encode their traffic with gzip (or alternative)
The HTTP gzip transfer encoding applies to the body of the message,
not the headers.
You may want to take some of the most common permutations of media
types sent in a request and register a new media type representing
that combination.

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 11 Jan 2007 17:20:27 -0800

> types sent in a request and register a new media type representing

We've been near here before. Consider 

"Identifying Composite Media Features"
               http://www.ietf.org/rfc/rfc2938.txt
uses hashes of feature set lists
   (http://www.ietf.org/rfc/rfc2533.txt)

and "MIME Content Types in Media Feature Expressions"
    http://www.ietf.org/rfc/rfc2913.txt
   
in conjunction with
"Transparent Content Negotiation in HTTP"
   http://www.ietf.org/rfc/rfc2295.txt

Larry

---

From: David Morris <[email-masked]>
Date: Thu, 11 Jan 2007 18:30:06 -0800 (PST)

> Wouldn't large sites encode their traffic with gzip (or alternative)

Hard to generalize from extensive case by case examination, but Google is
the only site I've observed which uses gzip. Over the past several years
I've spent a lot of time measuring page load timing for  well and not so
well known sites and not observed use of gzip.

Dave Morris

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 12 Jan 2007 04:57:30 +0100

> well known sites and not observed use of gzip.

google is far from alone in using gzip.

dynamic "content-encoding: gzip" appears to be spreading quite rapidly
over the Internet, largely because it's trivial to configure in most web
servers these days.

I don't have any readily available statistics, but it looks like it's a
fairly significant percentage of the web sites using this today.

Now if they only did it correctly and not as if "content-encoding" was
"transfer-encoding". But we already been in that discussion.. but on the
good side at least some vendors start to recognize that on-the-fly gzip
is really best done as transfer-encoding and not content-encoding..

But related to this discussion I expect to have quite interesting
statistics wrt HTTP header compression in a few weeks. I'll take a note
to return with this data.

Regards
Henrik