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:[EMAIL PROTECTED] Sent: 20. januar 2006 19:37 To: HttpClient User Discussion Subject: Re: MultipartFileUploadApp succeeds uploading file - but not upploaded 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 authentication! > 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. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
