I need to send X number of files to my servlet from an applet, which is the best way to do this?
And I need to send before the files, a java object populated.
I need to do it all in a single connection.
I'll upload my applet 3 ~ 10mb to my servlet.
I currently use FileInput together with the OutputStream and BufferedOutputStream to send a file, causing the buffer size is 8K.
First time I'll try to zip all the files to upload a zip file to the servlet, but I know it's not a good solution.
In the Applet side, send it as a normal multipart/form-data request by either URLConnection or HttpClient. In the Servlet side, use either HttpServletRequest#getParts() or Commons FileUpload to extract the parts from the request. This way the applet and servlet are not tight coupled to each other, but just reuseable on different servers (e.g. PHP) and/or clients (e.g. a simple HTML page).
Whether or not to zip the individual files into a single zip file is a decision you'd need to make yourself based on coding and performance impact.
Related
A text file is located at http://example.com/myText.txt with read and write permissions.
How can I append some line of text on top of it using Java. I see examples with the class OutputStreamWriter but they all use a file as an output. What about http?
(I need the code to be compatible with Java 5)
HTTP in the sense you understand it does not support any write operation of this nature.
There is no clear relationship between a URL and a file on the server; Specifically HTTP GET generally returns you a file-like resource if the URL refers to a web-like server; but the outcomes of HTTP POST are not simply an overwrite of the remote url file they are processed on a case by case basis by the other side.
If this is really what you want I strongly suggest you use FTP which is intended for this purpose.
There is no generic solution to this other than reading the content, appending the line locally, and writing it back with PUT (and that requires that the server supports the PUT method).
I need to write REST resource that should receive a file and save it to the disk.
The files will be sent from jersey client.
For now, I see two options:
1. Using multipart
2. Just reading the inputstream as a string and saving it to a file.
What are the pros of using multipart? is it related to file size? or anything else?
Thanks
If you use Jersey server side, using multipart you gain
disk buffering (surely you don't want to retain huge files in memory)
automatic base64/binary stream conversion
If you choose the String option these benefits are unavailable.
See also my answer to the question JAX-RS Accept Images as input, there is a sample implementation of the multipart option
I serve up files from a Jetty webserver which presently get downloaded via regular HTTP GET.
However, I am interested in a P2P model where users can download files via the webseeding. How would this be implemented in the context of a Jetty server with libtorrent?
Second, I dont want to "seed" ALL files on the Jetty webserver forever, instead I only want to be able to seed files "on demand".
For example rather than blindly seeding a torrent, I would like to have the file available for demand IF a request comes in for it (via GET or webseeding or whatever) - upon which it can be "seeded".
I want to seed or upload on demand because I have a multitude of files and do not know if I will be able to seed tens of thousands of files concurrently. Btw would anyone know what the upper limit is for number of files which can be seeded concurrently?
The relevant documentation about the libtorrent part is here: http://www.rasterbar.com/products/libtorrent/manual.html#http-seeding and the specs are http://bittorrent.org/beps/bep_0019.html and http://bittorrent.org/beps/bep_0017.html (both being supported by libtorrent, as "url seeds" and "http seeds").
IIRC, BEP19 (webseeds, or urlseeds) is rather straight-forward from the server POV, and you don't need to do anything special there - you just serve the files as you would do for a normal HTTP requests for that file (so, the second part of your question doesn't quite make sense here).
With BEP17, you rather use a unique http endpoint, and pass it get parameters to specify what the client wants (which for example allows for better throttling control and range selection) (eg: http://example.com/seed/?info_hash=X&piece=Y&ranges=Z).
This second approach is more flexible if you intend to have more (programmatic) control over what is downloaded, but obviously requires a lot more code to write to handle the requests though.
Again, from the server POV, this is not that different from regular HTTP transactions, and there is nothing special about "seeding" here. You just serve files (each with its own url, either directly, or via a handler).
A for the metadata part, with BEP19, you add a "url-list" extension (with the full url of your file: http://example.com/seeds/SOMEFILE.txt - watch out for multi-file torrents), whereas BEP17 uses the key "httpseeds" (with your endpoint, eg: http://example.com/seed/).
Depending on whether your Jetty also handle metadata generation or not, you might prefer BEP19 over BEP17, for your urls to be more predictable / the metadata generation to be simpler...
Hope that helps.
On the network where I have my web server there is a machine that has many zipped pdf files (zipped using java.util.zip) and I can access these files through HTTP. When a user wants to download a pdf file, I know how to unzip the file locally on the server first and then deliver the unzipped pdf to the user through a servlet. Is it possible to deliver the unzipped file to the user without unzipping it locally first?
Regards
In principle, if the client has said in his request that he accepts gzip-compressed data, you could send the PDF file in compressed form, and the client will decompress it. There is a gotcha, though: While the compression algorithm of zip files and the HTTP Content-Encoding: gzip is the same, the Zip file format has some more things around it (since it can contain multiple files, and a directory structure), so it would be necessary to strip these things off before. I'm not sure this would be much easier than decompressing in your servlet and then let your Servlet-engine take care of compressing again, but try it.
You can send the response to a request, encoded in a compressed format. If the client does the request with the header
Accept-Encoding: gzip, deflate
you can for instance serve him the content compressed using gzip (as long as you declare this through a header:)
Content-Encoding: gzip
Source: Wikipedia: HTTP Compression
Is it possible to deliver the unzipped file to the user without unzipping it locally first?
That depends a little bit on what exactly you mean with "locally", the general answer is "no". To deliver unzipped content, you have to unzip the zip first.
If you actually mean that the zip file is located at some non-local machine and that you currently need to save and zip it locally first before streaming unzipped content, then the answer would be "yes", it is possible to unzip and stream it without saving the file locally. Just pass/decorate the streams without using FileInputStream/FileOutputStream.
In firefox 2 I was able to get the path using Browse - I use the path in our project to then write out files to that location. So now that browse does not get the path, does anyone know a way for a user to go to a directory and have the path returned via a web page so I could pass that along to the server for processing?
execCommand does not work in firefox and had limites save type capaility, and entering by hand is not a useable option. Thanks.
The ability to see a complete client file path is now considered a security risk, and all modern browsers prevent you from seeing it (both via Javascript and via information sent back to the server on the form POST).
This is not possible with HTML/JavaScript. In HTML you can at highest use <input type="file"> to select a file, but not a folder or so. In JS you can't do anything at the local disk file system, let alone with a <input type="file"> element in the DOM tree. You're prohibited by security restrictions (you as being an enduser would of course not like if websites are able to do stuff at the local disk file system unaskingly).
You can only do that with a small application which runs straight at the client machine. For example a (signed!) applet which is basically just a piece of Java code served by a webpage which runs right at the client machine. You can communicate between applet and servlet using java.net.URL and consorts. Then, in the applet use Swing's JFileChooser to have a folder or file selection dialogue.
Update: by the way, MSIE and some other ancient browsers sends the full client-side disk file system path along the <input type="file"> to the server side. This is technically wrong (only the filename+extension should have been sent) and completely superfluous. This information is worthless in the server side, because it cannot access the file using the normal java.io.File stuff (unless both the server and the client runs at physically the same machine which of course wouldn't occur in real world). The normal way to get the uploaded file is to parse the multipart/form-data request body (for which one would normally use Apache Commons FileUpload or the Servlet 3.0 provided HttpServletRequest#getParts()).