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 10:57:36 UTC