W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: Comments on the HTTP/1.0 draft.

From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
Date: Wed, 30 Nov 1994 05:25:22 -0800
To: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9411300525.aa00164@paris.ics.uci.edu>
Marc VanHeyningen writes:

> Generally, I think the draft of Nov 28 is very good.


> Rather egregiously missing is a reference to transmitting network
> objects in canonical form.  Section 3.2 should mention this; a
> reference to the canonical encoding model in Appendix G of RFC 1521
> (specifically step 2) probably should suffice.  The only place this is
> hinted at is in the tolerance section of the appendices on tolerance
> of broken implementations, but the spec should explicitly say what the
> proper behavior is, just in case any servers every actually do that. :-)

The specified behavior will be "no canonical encoding of the object-body
is required before network transfer via HTTP, though gateways may need
to perform such canonical encoding before forwarding a message via a
different protocol.  However, servers may wish to perform such encoding
(i.e. to compensate for unusual document structures), and
may do so at their discretion."

> As near as I can tell, the spec constrains all header values to be
> US-ASCII, meaning nothing that is not US-ASCII may be contained in
> them.  We might consider permitting non-US-ASCII information in at
> least some headers, probably using RFC 1522's model.

I'd rather not.  If there is a perceived need for non-US-ASCII information
in header field value text and comments (I don't see any), then I think
they should only be encoded by gateways during export.

> In section 7.5, I don't understand the BNF for the CTE header.  CTE's
> don't have subtypes or parameters.

Just trying to improve the world we live in. ;-)
Okay, okay, I'll fix it.

> Regarding busy server errors, a "Retry-After:" field might be
> reasonable, but I would prefer to just make it an HTTP-date rather
> than inventing something new for clients to have to parse.  If we were
> going to use relative dates, there are plenty of other places (like
> Expires:) where they make as much sense.  A pointer to an alternative
> address also seems like a sensible way to handle timeouts.

Actually, I was going to propose adding an optional delta-seconds
for Expires as well, but not until HTTP/1.1.

......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
Received on Wednesday, 30 November 1994 06:05:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:10 UTC