W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 1997

Re: Content-Coding on POST

From: Larry Masinter <masinter@parc.xerox.com>
Date: Thu, 11 Sep 1997 08:59:31 PDT
Message-Id: <34181563.71D4A3A1@parc.xerox.com>
To: Dave Kristol <dmk@research.bell-labs.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4388
> Apropos the discussion of compressing HTML, I have the following
> question:  suppose a user agent wants to apply a Content-Coding
> to an entity it wants to POST.  How does it know what encodings
> the origin server accepts?

There's no way to communicate a server's preference for encodings
or formats in HTTP.

In RFC 1867 ("file upload..."), an HTML form can contain an "Accept"
attribute, as in <input type=file name=blah
accept="application/postscript">, but there's no corresponding
Accept-Encoding.

There's a proposal for extending ESMTP to add content negotiation
using HTTP Accept headers:
     draft-wing-smtp-capabilities-00.txt

in which the recipient (SMTP server) asks for capabilities of
the remote server.

I could imagine adding another operation in which an HTTP client
could ask a HTTP server, for a specific URL, to send appropriate
request headers, including accept-encoding, accept, etc.. I think
it is per-URL, though, and probably should have an Expires date
on it. (Maybe the response is a message/http body, so that the
normal cache headers could apply to the body.)

Larry


-- 
http://www.parc.xerox.com/masinter
Received on Thursday, 11 September 1997 09:04:07 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:03 UTC