RE: New MIMEtype to ask for HTML HEADs? Other suggestions?

An equally backwards-compatible way is to define a new header:
	Accept-Meta: header1, header2,...
which could go along with GET, HEAD, etc. requests, and ask that the
info corresponding to those headers be returned, but would be a hint not
to include too much more.

HTTP/1.0 and 1.1 servers that didn't understand Accept-Meta would send
all the entity-headers, but others would returns a more manageable
number.

>----------
>From: 	Jeffrey Mogul[SMTP:mogul@pa.dec.com]
>Sent: 	Thursday, December 19, 1996 10:40 AM
>To: 	Alejandro Rivero
>Cc: 	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Subject: 	Re: New MIMEtype to ask for HTML HEADs? Other suggestions? 
>
>    We are beginning to have some valuable head part in HTML documents;
>    META, PICS (?), TITLE, LINK,...  so this part is beggining to be a
>    document on his own.
>
>    Now, I wonder which would be the adequate method to retrieve all
>    this information. Clearly the old proposal of traslating META to
>    www-*: and then sending it in a HTTP HEAD is impractical, both by
>    size and consistency considerations.
>
>    So I see two alternatives: To ask for other file type, say
>    text/htmlhead, or to ask for some specific feature list whose
>    answers results to be only the head of the html.  The first
>    alternative has the adventage of compatibily with 1.0, so it could
>    be done with current servers.
>
>    I can not think of other ways. A new HTTP method, by example, would
>    be excesive, and would introduce an spureous dependence between
>    html and http.
>
>HTTP/1.1 introduces the ability for a client to ask for a subrange
>of the bytes of a resource.  For example,
>	GET /foo.html HTTP/1.1
>	Range: bytes=0-1023
>would retrieve the first Kbyte of the file (or to its end, whichever
>is shorter).  Later on, the client could do
>	GET /foo.html HTTP/1.1
>	Range: bytes=1023-
>to get the rest of the file.  (Note that this works for any file
>type, not just HTML.)
>
>If most HTML authors (or authoring tools) put the useful information
>at the very front of the file, then a client that wants to get the
>head information, but not the entire file, can do this and succeed
>with high probability.  If the useful information is longer than
>the requested subrange, it's not a big problem; just request some
>more.  If it's shorter, that's also not a problem; just ignore the
>extra stuff.
>
>Note that this is fully compatible with HTTP/1.0 servers, in the
>sense that the client will always receive at least as much data
>as it wants (although it may receive more), because HTTP/1.0 servers
>simply ignore "Range:".
>
>-Jeff
>
>

Received on Thursday, 19 December 1996 12:38:50 UTC