Receive file via websocket and save/write to local folder - websocket

Our application is entirely built on websockets. We don't do any HTTP request-reply. However, we are stuck with file download. If i receive file content via websockets can I wrote to local folder on user computer ?
If it makes a difference, we are only supporting Chrome so not issue if it doesn't work on other browsers.
Also, I know i can do this via HTTP. Trying to avoid it and stick to websockets since thats how the entire app is.
Thanks a lot in advance!

The solution depends on size of your file.
If size is less than about 50 MB, I would encode file's content to base64 string on the server and send this string to the client. Client should receive parts of the string, concat them to single result, and store. After receiving whole string, add link (tag <a>) to your page with attribute href set to "data:<data_type>;base64,<base64_encoded_file_content>". <data_type> is a mime type of your file, for example "text/html" or "image/png". Suggest file name by adding download attribute set to name of file (doesn't work for Chrome on OS X).
Unfortunately I have no solution for large files. Currently there is only FileEntry API that allows to write files with JS, but according to documentation it is supported only by Chrome v13+, learn more here https://developer.mozilla.org/en-US/docs/Web/API/FileEntry.

Related

How to download file using ProtoBuf

I'm trying to implement file download directly via Browser. Our company uses Protocol Buffer as data communication format. So how can I download the file once I open the web page?
I tried to user bytes and stream of Protocol Buffer. But the result is
{"result":{"data":"Cw4ODg4ODgsMCw4ODg4ODgsMTUwMCwwLDE1MDAsNDAwMDAsMTAwMDAsMzAwMDAKMDMvMTEvMjAxNSxVbmtub3duIEl0ZW0sUHJlIFJvbGwgVmlkZW8gKG1heCAwOjMwKSw2MDAwMCwzMTAwMCwyOTAwMCw1MDAwMCwyNDAwMCwyNjAwMCwyMC4wMCUsODQ0NCwwLDQwMDAsNDQ0NCw4OTAzODgsMCwwLDAsODg4ODg4LDAsODg4ODg4LDE1MDAsMCwxNTAwLDQwMDAwLDIxMDAwLDE5MDAwCg=="}}
Protobuf is good for structured communication but http provides the perfect protocol for downloading files. The right headers need to be set and the browser will download the file.
If you really have to use protobuf to transfer files, then you need to add some javascript that is parsing the protobuf first and then turns it into a file that can be downloaded. See How to create a dynamic file + link for download in Javascript? for reference.
So, send the message as bytes, add the javascript that parses the protobuf message to extract the bytes, and then create the file download like on the linked answer.

How to decode and inspect an HTTP payload when it is a zip

So I'm pretty new at all this. I am trying to reverse engineer a web application.
When I submit a form, it sends a POST with a request payload that looks something similar to this:
encoding=UTF8&zip=1&size=136240&html=DwQgIg_a_whole_lot_more_gibberish_not_worth_posting
Anyways, from inspecting the captured traffic from Chrome developer tools, I noticed it is encoded and sent as a zipped up html?
How would I go about reversing this to see what the content is actually being sent to the server?
What you want to do is this:
1) Get the name of the zip file
2) Get the path of the zip file (likely the root directory or the current path the form is at)
3) Generate the URL (http://site_name.com/path/to/folder/zip_file.zip)
4) Download it using a too such as wget (typing the URL into the browser may work too)
I used this technique to download all the files that get downloaded to the OTA updates on iOS devices (used burp suit to intercept the zip file name where the server was on my computer which my iDevice was connected to).
Please note: the name of the zip file you have given does not end in .zip. this may mean it doesn't have a extension; you may have to add .zip to the file manually; or it may have another ending such as .tar, .tar.gz etc.

What's the fastest way to upload an image to a webserver?

I am building an application which will allow users to upload images. Mostly, it will work with mobile browsers with slow internet connections. I was wondering if there are best practices for this. Does doing some encryption and than doing the transfer and decoding on server is a trick to try ? OR something else?
You would want something preferably with resumable uploads. Since your connections is slow you'd need something that can be resumed where you left off. A library i've come across over the many years is Nginx upload module:
http://www.grid.net.ru/nginx/upload.en.html
According to the site:
The module parses request body storing all files being uploaded to a directory specified by upload_store directive. The files are then being stripped from body and altered request is then passed to a location specified by upload_pass directive, thus allowing arbitrary handling of uploaded files. Each of file fields are being replaced by a set of fields specified by upload_set_form_field directive. The content of each uploaded file then could be read from a file specified by $upload_tmp_path variable or the file could be simply moved to ultimate destination. Removal of output files is controlled by directive upload_cleanup. If a request has a method other than POST, the module returns error 405 (Method not allowed). Requests with such methods could be processed in alternative location via error_page directive.

Implementing my own protocol and using it through my browser

I want to create a new protocol so that I can view the data retrieved through the protocol in the browser.
For example, I want to be able to go to myprotocol://www.filepath.com/img.jpg and view the image.
Where myprotocol is defined by myself.
I have read about registering application handling here:
http://msdn.microsoft.com/en-us/library/aa767914%28v=vs.85%29.aspx
with this it is possible to run a desktop exe that receives the url I am trying to access. How would I return the retrieved jpg to the browser for viewing, so that it behaves like a normal protocol, such as http?
Thanks
That registration will allow you to bind an application to the uri, so if launched through windows explorer (including "Run") and from command line, then the app is launched and the uri passed to it as an argument (much like if you double-click a file, the default app for it is launched and the path to the file passed).
For example, your "default" browser will have http:// associated with it in this way.
It is still up to the application itself to have its own handling of the URI when it is passed as an argument. If you want to make a browser handle your new protocol, you will have to write an extension/plugin/add-on/whatever-that-browser's-makers-call-it to add further functionality to the browser. This is a separate job for Firefox, IE, Chrome, Konqueror, Chromium (well, at least it might be sharable with Chrome), etc. with separate APIs to deal with.

Servlet send image from server and save in client

I'm new and just developing on J2EE.
I am modifying an existing application (an OpenSource project).
I need to save an image on a client sent by the server, but I do not know how.
This activity must be done in a transparent manner without affecting the existing operation of the application.
From the tests done I get this error:
java.lang.IllegalStateException: getWriter () has Already Been Called for this response.
How should carry out this task, according to your own opinion?
How do I save on the client, locally, the image?
Update:
Thanks for the answers.
My problem is that:
the image is generated on the server, but not for direct client request (there is no link to click on web page), the picture is composed using other services on the Internet.
reconstruct the image on the server.
This image must be sent to the client to be saved locally.
so I'd like it to appear a window where you assign the destination image
plus I'd like the rest of the application were not affected by this activity.
The application is yet on production.
Thank you very much for your response.
From the tests done I get this error: java.lang.IllegalStateException: getWriter () has Already Been Called for this response.
In other words, you were trying to mix the binary data of the image with the character data of the HTML output, or you were trying to do this in a JSP instead of a Servlet. This is indeed not going to work. You need to send either the image or the HTML page exclusively in response to fully separate requests.
In your JSP/HTML page just have a link to the image, like so:
click to download image
Then, in a servlet listening on an url-pattern of /imageservlet/*, you just get the image as InputStream from some datasource (e.g. from local disk file system as FileInputStream) and then write it to the OutputStream of the response the usual Java IO way.
You only need to set at least the Content-Disposition response header to attachment to make sure that the client get a Save As popup dialogue, else it will be displayed straight in the browser. Setting the Content-Type and Content-Length are also important so that the browser knows what the server is sending and can predict how long the download may take.
response.setHeader("Content-Type", getServletContext().getMimeType(file.getName()));
response.setHeader("Content-Length", String.valueOf(file.length()));
response.setHeader("Content-Disposition", "attachment;filename=\"" + file.getName() + "\"");
You can find complete basic servlet example in this article.
Note: you cannot control where the client would save the image, this would be a security hole. This way websites would be able to write malicious files on client's disk unaskingly.
Update: as per your update, there are two options:
You need to let the client itself fire two HTTP requests (I've answered this in your subsequent question)
Create a client side application which does all the task directly at the client side and then embed this in your webpage, for example a Java Applet. With an applet you have full control over the client environment. You can execute almost all Java code you'd like to execute and you can write files to disk directly without asking client for the location to save. You only need to sign the applet by a 3rd party company or the client needs to confirm a security warning before running.
Its up to the browser how all types of output are handled. Web pages are given a content type of html which the browser understands and ends up rendering ass a page that we can see. Images are given content type of image/jpeg etc which are rendered as images when in a page etc. To force a download prompt one needs to use a content type of a binary file rather than that of an image so the browser forces the download rather than shows the image. To ensure this use something like "application/octetstream"... i cant recall exactly but its easy to google for.

Resources