hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Ove Skjaervik" <geiro...@online.no>
Subject RE: MultipartFileUploadApp succeeds uploading file - but not upploaded
Date Fri, 20 Jan 2006 22:55:04 GMT
Hello Roland,

Thanks for your answer. I do know that HTTP is a text protocol. If
memory serves me well, HTTP and HTML was originally developed by a Cern
physicist. The sad thing is that when the protocl became popular, it was
not improved to support non text transfers that it is also used for:
Instead it became a very messy patch with all kinds of extensions.  I
have written a few protocols myself long time back when modems and 2400
baud was "insane" speed....

My problem is that I have not worked with HTTP procols and just a little
with servlets and jsp, but do need to be able to upload files with HTTP
when a customer do want it! So, I do indeed know that HTTP is not well
suited for it, but users may not know, and still want to do it!

Oh well, we got to live with it :-)

Geir Ove

-----Original Message-----
From: Roland Weber [mailto:http-async@dubioso.net] 
Sent: 20. januar 2006 19:37
To: HttpClient User Discussion
Subject: Re: MultipartFileUploadApp succeeds uploading file - but not

Hello Geir Ove,

> Using HTTPClient I tried to upload a File to a HTTP Internet 
> Information Server directory that I set up.

Please understand that, unlike NFS, HTTP is *not* a file access
protocol. HTTP is a client/server protocol to access generic documents,
and most HTTP servers support a server-side file system as a document
repository out of the box. Also, any HTTP server with sensible default
settings will
*not* give you write access to that repository. Let alone without user

> HTTClient then gave a sensible error
> message:
> Uploading filetoupload.txt to http://aika:80/uploads/
> Upload failed, response=Method Not Allowed

HttpClient gives you the exact error message the server sends back.

> Shouldn't HTTClient do the same towards Tomcat when? I do not know 
> whether Tomcat, HTTClient or both are to blaime: It maybe another 
> lacking in the messy HTTP Protocol.

See above for the scope of the HTTP protocol. What a server does in
response to a POST request is not defined anywhere but in the server and
it's documentation. POST is often used to submit some parameters from a
form, and the application on the server usually retrieves or generates
some document for the client. IIS refuses the POST request. That's a
fair behavior. Tomcat ignores the data sent with the post request and
returns the document referenced by the URL to which you posted. That's
also a fair behavior.

> The only way I know can check if Tomcat really did what it was 
> supposed to do, is to parse the response and see if the file is 
> present: Again a messy business, as there does not seem to be a 
> standard format for the Directory Listing ! Or am I wrong?

See above: HTTP is not a file access protocol. Hence, it knows nothing
about directories. The modules in the HTTP server that use the file
system as a repository generate a document from the directory if they
are configured that way. That's nothing but a document, which happens to
be generated dynamically instead of being stored statically.

If you want the server to store a file you upload, you can either search
for a module that does it and configure that module, or else you can
implement and install an application (meaning: a servlet) that knows how
to interpret the data in the request you send. If you're in a really
(w)hacky mood, you can just put that code into a JSP, then send the POST
request to the URL of that JSP. There are other methods than GET and
POST. For example, there is a method PUT specifically designed for
uploading files. And a status code 201 to indicate that a resource has
been created on the server. Again, it takes a server-side application to
interpret the request and generate the response, and it is your
responsibility to provide it (assuming you are running the server).

I hope that clarifies things a little.


To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org

To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org

View raw message