(no subject)

Ref posts from: Roy T. Fielding and Henrik Frystyk Nielsen

Many thanks for the rapid responses.  Just a couple of follow-ups:

> > I was very pleased to see the new HTTP draft; it's a major improvement
> > on previous versions!  Here are some comments on the new draft which I
> > hope will be useful.
>
> Thanks, these comments are definitely useful.  Unfortunately, they refer
> to the pre-Internet-Draft version, so I'll try to point out any differences
> in the section numbering to avoid confusion.
[aside] Odd: the version I have proclaims itself "This document is an
        Internet-Draft".  Problems with document control somewhere!
        How will the Real Internet-Draft be identified?

> > 3.2 Object body:
> >
> >     (a) This is my 'biggest' question -- I don't understand from the
> >     second paragraph how to determine when to stop reading the data on a
> >     request.  If the headers are only 'similar' to those defined by
> >     MIME, then the MIME definition may or may not be relevant.
> >     Moreover, a "heuristic function of the Content-Type and
> >     Content-Encoding" would appear to be unimplementable, as new Types
> >     (especially application/xxx) seem to spring up daily.
>
> Henrik asked me to explain that as well, but I ran out of time.
> It goes something like this:
>
>    a) If message includes Content-Length, use it.
>
>    b) If message uses an as-yet-undefined packetized Content-Transfer-Encoding
>       then that encoding may define an EOF marker.
>
>    c) If message uses an as-yet-undefined packetized Content-Encoding,
>       then that encoding may define an EOF marker.
>
>    d) If message is of type multipart/*, the effective object body ends
>       when the boundary close-delimiter is reached.
>
>    e) If the connection closes, the object body has ended.
>
> Part (b) is along the lines of Dan Connolly's www-talk proposal of 27 Sep 1994
> (Message-Id: <9409271503.AA27488@austin2.hal.com>).

I'm happy with the situation for responses (connection closes is quite
good enough), but still very unhappy with this definition for the data
(object body) for requests (PUT and POST).  The steps you just
outlined are not defined sufficiently well to be implementable (and
requiring every server to implement the rather gawky multi-part stuff
just in case data comes in that way seems unnecessary).  Is not
Content-Length essentially always present, in current practice, for
PUT and POST?  In which case, why require more that this, or
alternatives, unless truly necessary?

> >     (c) [aside] I wish, oh wish, that Longitude/Latitude information
> >     were a recommended header.
>
> [aside] it's too inefficient to include that in every response.  A standard
> URL for site info is more appropriate.
[aside] Maybe, but Long/Lat is more useful to the user than date/time
        of server response, and there *is* no standard for site info.

> > 5.  Request: The 0.9 requirement here (Simple Request must have Simple
> >     Response) is somewhat onerous on a server.  Is it possible to relax
> >     or remove this requirement yet, or are there still 0.9-only clients
> >     in use?  I've noticed that at least some Simple Responses will not
> >     go through some proxies transparently.
>
> I believe proxies require Full-Requests.  Ari?
> I do not believe it is possible to remove that requirement, though perhaps
> we should require that HTTP/1.0 clients never generate a Simple-Request.
Excellent suggestion.  Please do.

Mike Cowlishaw

Received on Thursday, 1 December 1994 12:01:29 UTC