JSF resumable File Upload - http

I want to upload files with JSF. I want to be able to resume an upload after a pause (voluntarily or not).
They will be about 500Mb in size.
I'm working with PrimeFaces, which has a neat FileUpload-Tag, but it doesn't let me pause/resume uploads.
I did some research on this. The most common answer is "Use an FTP-Client". Others were Java-Applets or Flash.
It should work on the current Firefox/Chrome and IE8.

It's indeed not possible to resume file uploads via HTML <input type="file"> element. There's namely nothing in the multipart/form-data encoding which would ever support that. Even more, there's no standard form encoding specification which supports that. You'd basically need to invent a custom HTTP request format.
In Java terms, your best bet is to homebrew an applet or webstart application for this which uses Swing JFileChooser to pick files and uses URLConnection to send it via HTTP to the server. In the server side, you'd need a custom Servlet which understands the custom request format and processes the partial upload accordingly.
There's a 3rd party applet which is capable of this all: JumpLoader. Its homepage is at the moment unfortunately down (you could however try Google Cache). To the point, it sends some specific HTTP request parameters along with the multipart/form-data upload request telling the server side if it's a partial upload and if so at which index it should start, so that the servlet can glue the pieces together.
Then, to integrate this all with JSF, your best bet is to let the applet pass the session ID around as URL path fragment so that the servlet shares the same HTTP session as the JSF application. This way the upload servlet can access session scoped JSF managed beans and/or the JSF application can poll for some servlet-specific variables in the HTTP session.

Related

How the server really handle the response to a http request?

I understand that the server send website components to the client after http request, HTML, CSS, Js and other static files that are necessary to build the website in the client browser.
I want to understand what the server actually do to generate the response since it should handle many requests not just one request??
I assume that the server create an instance from the files and send it to the client via http response?? is this right, wrong,inaccurate or incomplete or are there other processes that happen on the server to make it work??
These "website components" (code for the browser) can be created by the server however it wants. There are two typical patterns. Static and dynamic.
Static resources are created ahead of time. These cannot be customised by the server at the time of the request.
Dynamic resources will be generated when the request is received. For example, a HTML asset may be generated to include a particular user's username as found in a cookie sent with the request. This is typically done from templates like jinja2 for Python.
Nowadays serving these resources statically and using a client side JavaScript application with a separate data API to customise content is the most popular way to build interactive websites (web apps)

Accessing js-enabled "links" from a JSF page via curl/raw http

I am trying to work out how to access content on this site: https://handbook.unimelb.edu.au/
I can manually conduct a search via the browser, and I am tracking the raw http request via HTTP live Headers, but having endless problems working out how the system is actually conducting search.
In particular, using the advanced search via: https://handbook.unimelb.edu.au/faces/htdocs/user/search/AdvancedSearch.jsp
Results in data similar to the following being sent:
POST /faces/htdocs/user/search/AdvancedSearch.jsp HTTP/1.1
AdvancedSearchForm%3Akeywords=&AdvancedSearchForm%3ACourseOrSubjectSelection=SUBJECT_ALL&AdvancedSearchForm%3AGraduateLevelSelection=POSTGRADUATE_ALL&AdvancedSearchForm%3AfacultyList=&AdvancedSearchForm%3AdepartmentList=&AdvancedSearchForm%3Alevel=ALL&AdvancedSearchForm%3Asemester=ALL&AdvancedSearchForm%3AallStudyAreas=t&oracle.adf.faces.FORM=AdvancedSearchForm&oracle.adf.faces.STATE_TOKEN=_id51018%3A_id51019&source=AdvancedSearchForm%3AsearchButton
The server immediately responds with "HTTP/1.1 302 Moved Temporarily" and redirects me to "Location: https://handbook.unimelb.edu.au/faces/htdocs/user/search/SearchResults.jsp"
Which actually displays the search results.
As far as I can tell, the search itself must be using a session to store the searched-for terms between the post and the subsequent get.
Is this normal JSF behaviour?
Is there a trick to accessing such a system?
Is this normal JSF behaviour?
This bahaviour is not "normal". This approach is however explainable for legacy JSF 1.x applications; it's because GET forms weren't natively supported by JSF 1.x. I would however consider this approach rather poor design and have recommended to use <managed-property> to inject GET request parameters. The webapp architect/developer has most likely not really thought it out very well. Note that since JSF 2.0, which is out for little over 3 years already, GET forms using plain HTML <form> are natively supported thanks to the new <f:viewParam> tag.
Is there a trick to accessing such a system?
Tell your HTTP client to maintain the session (read: the cookies) and auto-follow redirects. By default, JSF relies heavily on the session already as it stores the view state in there as well. This is in turn not related to the way how that webapp is designed.
See also:
How can i programmatically upload a file to a website? - related answer on how to properly programmatically submit a JSF based form.

Hide all redirect informations

I'm using Response.Redirect to serve media files, but don't want people to see the direct url to the files nor the subdomain (host). Is it possible to fake a 'get', and hide host and referer?
Use a Server.Transfer to transfer the request processing to another page.
When you use the Transfer method, the state information for all the
built-in objects are included in the transfer. This means that any
variables or objects that have been assigned a value in session or
application scope are maintained. In addition, all of the current
contents for the Request collections are available to the .asp file
that is receiving the transfer.
Server.Transfer acts as an efficient replacement for the
Response.Redirect method. Response.Redirect specifies to the browser
to request a different page. Because a redirect forces a new page
request, the browser makes two requests to the Web server, so the Web
server handles an extra request. IIS 5.0 introduced a new function,
Server.Transfer, which transfers execution to a different ASP page on
the server. This avoids the extra request, resulting in better overall
system performance, as well as a better user experience.
Since the browser doesn't make another request, the url is totally hidden from the browser, but it still gets the file that will be served by your redirect url.
What you want is not possible - for a simple reason: To have the client download the file directly from another source, you need to communicate the information about the location to the client in some way: If the client doesn't know the location, it can't download from there.
Whatever you try in the way of obfuscation, if it is decodable for the client browser, it is decodable for a human being armed with firebug.

Receive requests with a .asmx file or a .aspx file?

I'm setting up my site to receive info from people via text message. The way it works is they text a number, that service then sends an HTTP POST to a url I specify. I've heard that .asmx files are better than .aspx files because they don't go through the whole page lifecycle. However, I don't really understand how to get a .asmx file running, and can you even call it with a POST, ie, www.mysite.com/webservice.asmx? I know I can make it work with a .aspx file, but I wanted to check to see if there was a better way before I undertake this endeavor.
Thanks for your insight!
While any extension can be mapped to any handler in ASP.NET, by default .aspx is mapped to page handler and .asmx is mapped to Web service handler. I think you are looking for .ashx which represents a generic simple handler. You just need to implement ProcessRequest method of the IHttpHandler interface after adding one to your project (Add New Item -> Generic Handler).
The .ashx works well if you want to manually process the request. Only if you want to provide a Web service (e.g. SOAP), you should go with .asmx. As a consequence, the best solution depends on the format of the HTTP POST request they send. If they send raw data in POST with their own specific protocol, go with .ashx. Otherwise, if they are using a standard RPC (SOAP, XML-RPC, ...) protocol, .asmx is probably better.
Create an .asmx file with Visual Studio. It should create a template with a HelloWorld method. Browse to it with your favorite browser and you'll actually get an explanation on how to post requests to it using various methods.
There is another type you haven't mentioned: ashx. However, in your case, a webservice (asmx) would make sense.

Better file uploading approach: HTTP post multipart or HTTP put?

Use-case: Upload a simple image file to a server, which clients could later retrieve
Designate a FTP Server for the job.
HTTP Put: It can directly upload files to a server without the need of a server side
component to handle the bytestream.
HTTP Post: Handle the bytestream by the server side component.
I think to safely use PUT on a public website requires even more effort than using POST (and is less commonly done) due to potential security issues. See http://bitworking.org/news/PUT_SaferOrDangerous.
OTOH, I think there are plenty of resources for safely uploading files with POST and checking them in the server side script, and that this is the more common practice.
PUT is only appropriate when you know the URL you are putting to.
You could also do:
4) POST to obtain a URL to which you then PUT the file.
edit: how are you going to get the HTTP server to decide whether it is OK to accept a particular PUT request?
What I usually do (via PHP) is HTTP POST.
And employ PHP's move_uploaded_file() to get it to whatever destination I want.

Resources