Re: Making POST (and PUT) requests
Subject: Re: Making POST (and PUT) requests
From: Henrik Frystyk Nielsen <firstname.lastname@example.org>
Date: Tue, 23 Jan 1996 18:32:32 -0500
From email@example.com Tue Jan 23 18: 32:54 1996
Reply-To: Henrik Frystyk Nielsen <firstname.lastname@example.org>
X-Mailer: exmh version 1.6.2 7/18/95
Mark S. Friedman writes:
> For the life of me, I can't figure out how to use the 3.0 version of
> the Library to POST (or PUT) documents. I can see the kludgey way that
> the proxy code in the DAEMON does it (by appending the POST data to a
> special set of HTProxyHeaders that the Library treats as a special
> case) but how does an ordinary program attach the POST data to a
> request? I see some skeletal support (i.e. the postStream field in the
> HTProtocol structure and a reference in the doumentation to "Functions
> for posting a document") but the meat seems to be missing.
> Is the stuff really there but I haven't found it? Is it there in 3.1?
> Is it there in 4.0?
Basically the functionallity is not there in 3.0. The first try of 4.0 had the
model but also enough bugs to not make the functionality really useful.
However, the new patch that I mailed earlier today seems to make up for it, so
let me explain what exactly you can do:
- You can PUT or POST a document _from_ either a remote HTTP server or the
local file system _to_ a remote HTTP server.
- The interface for doing this is called a POSTWeb which is described at
It is based on the model that the application binds together anchor objects
describing the relation between them and the method to be performed, for
example PUT. The Library then uses this information to build a similar
structure of Request objects and spawns off a set of connections. This model
is very flexible and allows for multiple destinations each with different
operations performed. However, the current implementation uses only one source
and one destination.
- The current implementation supports redirection and authentication on the
destination side but not on source side. If this was to be the case then the
Library can not build an internal web of request objects. Instead this must be
done in the application. Otherwise there is no way for the application to get
to the right request object when generating credentials. This is not a
limitation of the model but of the current implementation, especially of the
HTCopyAnchor function in the HTAccess module.
You can get the latest distribution from
Henrik Frystyk Nielsen, <email@example.com>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA