I'm currently writing some update polling stuff. I try to avoid writing even a simple REST-Interface for this (we're using much REST, still I'm not sure this is necessary here. Why write an interface for functionality already there?)
My idea was to open an HttpUrlConnection and check headers for file's last modified date. Apache obviously sends "Last-Modified" date in UTC. After checking the header I'd close the connection without actually retrieving the body. I only fear that this might bring up errors in Apache log, which would be quite inconvenient. I just wanted to ask for you opinion. Do you think this might work? Better ideas?
(I need system proxy support, so my only option seems to be HttpUrlConnection.)
Regards,
Stev
If you look at the HTTP protocol, you'll see that it has a HEAD request which does just what you need. The default for HTTP requests in the Java runtime is GET and it's not really easy to change that.
Have a look at HttpClient for a framework which allows you to send any kind of request.
You are almost right but your task is even simpler that what you are explaining. There is special HTTP method named HEAD. You just have to create the same request you need to retrieve your data but use HEAD instead of GET
This sounds pretty much, what the HEAD method in HTTP is for.
Citing from Wikipedia:
HEAD
Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.
Try just sending an http HEAD request. See here: http://blog.mostof.it/what-is-a-http-head-request-good-for-some-uses/
http://www.grumet.net/weblog/archives/http-head-example.html
Related
I just realized that my base64 encoded Header "Authentication" can't be read
with request.getHeader("Authentication").
I found this post about that it's a security Feature in URLConnection
getRequestProperty("Authorization") always returns null
, i don't know why but it seems to be true for request.getHeader as well.
How can i still get this Header if l don't want to Switch to other libraries?
I was searching through https://fossies.org/dox/apache-tomcat-6.0.45-src/catalina_2connector_2Request_8java_source.html#l01947 and found a section where restricted headers will be used if Globals.IS_SECURITY_ENABLED is set.
Since I'm working on a reverse Proxy and only Need to pass requests/Responses through I did simply set "System.setSecurityManager(null);" and for my case it might be a valid solution but if you want to use authentication there is no reason to use this Workaround.
My bad, it does work with https now.
The accepted solution did not work for me – may have something to do with different runtime environments.
However, i've managed to come up with a working snippet to access the underlying MessageHeader-collection via reflection and extract the "Authorization"-header value.
Bear with me as I know this question seems easily searchable but I've been stuck on it for some time and would greatly appreciate a thorough read-through before answering. I'm trying to write a very basic Java server, not to be scaled or implemented but just to understand networking. What is the best (in this case, simplest) method of parsing a request header to extract the filename? My current code uses a Socket to establish the connection, and in doing research I've seen:
Reading the socket's inputstream into a scanner/buffered reader and manually parsing it (by the leading / before the filename, I'm assuming)
Using default methods of HttpServletRequest (how do you generate an object of this type? Isn't an interface non-instantiable? Documentation is unclear about this)
Something with a "Content-Disposition Header"?
Thanks again for the help, these http API's seem very similar/overlapping to a rookie network programmer.
I have a situation where the client (.js) initiates a REST request and it is processed on the server side (.java). After processing, I would like to return a count to the client, which will be shown in a popup box if it is positive. How can such a construction be done? The idea I had was to set a named parameter on the HttpServletResponse object, but even this object is no where in scope in the .js code. Any ideas? I should also clarify that the primary purpose of the REST call is to download a file to the client. Thanks!
Do you want to send two things to your client - sending a file and also additional data? You haven't mentioned what framework (if any) you are using in backend to do this. You can use response header.
From your question, it seems like you don't have a good general-purpose way of responding to client requests on your server. I'd recommend you decide on a data format you'd like to use for all calls (e.g., JSON, XML, etc.) and stick with that across the board.
Once you've made that decision, you can encode your integer using whatever makes sense in your chosen format. For example, in JSON you might return: {"count":6}.
My current problem is very similar to this one.
I have a downloadFile(URL) function that creates a new HttpURLConnection, opens it, reads it, returns the results. When I call this function on the same URL multiple times, the second time around it almost always returns a response code of -1 (But throws no exception!!!).
The top answer in that question is very helpful, but there are a few things I'm trying to understand.
So, if setting http.keepAlive to false solves the problem, it indicates what exactly? That the server is responding in a way that violates the http protocol? Or more likely, my code is violating the protocol in some way? What will the trace tell me? What should I look for?
And what's the deal with this:
You need to read everything from error
stream. Otherwise, it's going to
confuse next connection and that's the
cause of -1.
Does this mean if the response is some type of error (which would be what response code(s)?), the stream HAS to be fully read? Also, every time I am attempting an http request I am basically creating a new connection, and then disconnect()ing it at the end.
However, in my case I'm not getting a 401 or whatever. It's always a 200. But my second connection almost always fails. Does this mean there's some other data I should be reading that I'm not (in a similar manner that the error stream must be fully read)?
Please help shed some light on this? I feel like there's some fundamental http protocol understanding I'm missing.
PS If I were just using the Apache HttpClient, would I not have to deal with all these protocol details? Does it take care of everything for me?
The support for keep-alive in the default HTTP URL handler is very buggy. We always turn it off.
Use Apache HttpClient with a pooled connection manager if you want keep-alive. If you don't want change your code, you can get another handler like this one,
http://www.innovation.ch/java/HTTPClient/
If your second connection always fails, that means your server doesn't support keepalive. With Keepalive, the HTTP handler simply leaves connection open (even if you call disconnect). The server closes connection if keep-alive is not supported but the handler doesn't know till you make next request on the connection so the 2nd connection fails.
Regarding the read error stream, it only applies if you get non-200 responses.
i think you're probably talking about this HttpURLConnection bug, fixed in froyo:
http://code.google.com/p/android/issues/detail?id=2939
see that bug for other workarounds. if this isn't the bug you've hit, please raise a bug with a repeatable test case at http://code.google.com/p/android/issues/entry.
I have a java applet for uploading files to server.
I want to display the % of data sent but when I use ObjectOutputStream.write() it just writes to the buffer, does not wait until the data has actually been sent. How can I achieve this.
Perhaps I need to use thread synchronization or something. Any clues would be most helpful.
Don't use ObjectOutputStream. It's for writing serialized Java objects, not for writing raw binary data. It may indeed block the stream. Rather just write directly to the OutputStream of the URL connection.
That said, the code looks pretty overcomplicated. Even after re-reading several times and blinking my eyes countless times, I can't get it right. I suggest you to send those files according the multipart/form-data encoding with help of Commons HttpClient. You can find here a basic code example. You just have to modify Part[] parts to include all the files. The servlet on the other side can in turn use Commons FileUpload to parse the multipart/form-data request.
To calculate the progress, I'd suggest to pick CountingOutputStream of Commons IO. Just wrap the OutputStream with it and write to it.
Update: if you don't like to ship your applet with more 3rd party libraries (which I imagine is reasonable), then have a look at this code snippet (and the original question mentioned as 1st link) how to create a multipart/form-data body yourself using URLConnection.
What I was looking for was actually:
setFixedLengthStreamingMode(int contentLength)
This prevents any internal buffering allowing me know exactly the amount of data being sent.