Henrik Frystyk, July 94
HTTP Put and Post Method
Note: This document is still under construction. Any
suggestions or ideas are welcome at libwww@info.cern.ch.
This document describes a concept of posting a single data object to
multiple recipients using one transaction from a World-Wide Web
client to a HTTP server using the HTTP
Protocol. The data object considered can be any arbitrary data
stream and hence is not limited to text objects.
A general posting interface between the Library
of Common Code and the client is described in
Client Interface for Posting. The interface is designed to be
flexible enough to include posting using the SMTP protocol, the NNTP protocol and possibly
other Internet protocols.
The HTTP protocol provides two possible Methods
for the client to transfer a data stream to the server:
- POST
- The POST method creates a new object on the remote HTTP server.
The client can specify a URI for future references but the server
may overwrite this and allocate a new URI for the posted stream. In
both cases the server returns a URI which can be used for future
references of the created document but a body is never included in the
response.
- PUT
- The PUT method is used for adding or modifying already existant
data on the remote HTTP server. That is, the URI passed from the
client must refer to an existant data object on the remote server. In
the body of the response, the server can include a data object, e.g.,
contain the modified version of the document or diffs between the new
and the old version.
The positive acknowledgement given from the server upon a completed
transaction using PUT or POST is no guarantee that the document later
can be referenced by the returned URI. In both cases the action might
be overwritten by system administration on the remote server.
Single Transaction Posting
The current specification of PUT and POST in the HTTP protocol is
based on having a single recipient for every posted data object. That
is, one HTTP request using PUT or POST can contain at most one URI as
the distination. However, as will be shown, this implementation is
limited and unsufficient to be a generic posting mechanism.
The problem arises when the user has build a posting WEB containing more than
one NNTP news group in the list of recipients. The posting mechanism
used in the NTTP protocol requires that all news groups are specified
as a comma separated list in the "Newsgroups" directive in the Standard for Interchange of
USENET Messages header. This approach requires that the total set
of recipients are known prior to the actual posting transaction.
If the client is not directly connected to the NNTP server but
accesses it through a HTTP Proxy
server the HTTP protocol must support this posting method as all
connections between the proxy server and the client are using the HTTP
protocol. Therefore a more general posting method has to be specified
in order to keep the HTTP protocol as a superset and not a subset of
existent protocols.
MORE...
A HTTP request using the PUT or POST method will in general
but additionally the following headers are generated:
Content-Type
If the content-type is not given from the client via the HTRequest Structure when sending a POST
request to the Library, then a content type is guessed by reading the
first part of the POST stream. You can get more information on the guessing
algorithm from HTGuess Module
Content-Length
If the content length of the POST body is not given in the HTRequest Structure
then it is calculated using the MIME Content Length Stream.
Content-Encoding
Only if this is set by the client a MIME Content-Encoding: header is
generated and send along the HTTP request
Content-Language
Only if this is set by the client a MIME Content-Language: header is
generated and send along the HTTP request
The HTTP Response
Posting to an Illigal URI
One problem having POST integrated in a stateless protocol such as
HTTP is that the client doesn't always know beforehand if it is legal
to post to an URI or not. Only if the client has actually received That is, what do a server do if a client
starts sending a stream of posting data and the server doesn't accept
POST as a legal HTTP
method? Two solutions are available for solving this problem:
- The client starts sending the posted stream without knowing
Two Way Links
The server who has received and effectuated a POST might want to keep a log
of
Henrik Frystyk, libwww@info.cern.ch, July 1994