W3C home > Mailing lists > Public > www-lib@w3.org > January to March 1996

Re: Making POST (and PUT) requests

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Tue, 23 Jan 1996 18:32:32 -0500
Message-Id: <9601232332.AA05589@www20>
To: msfriedm@us.oracle.com
Cc: www-lib@w3.org
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

	http://www.w3.org/pub/WWW/Library/User/Architecture/PostWeb.html

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

	http://www.w3.org/pub/WWW/Distribution.html


-- 

Henrik Frystyk Nielsen, <frystyk@w3.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA
Received on Tuesday, 23 January 1996 18:32:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 April 2007 18:18:25 GMT