aspose file tools*
The moose likes Sockets and Internet Protocols and the fly likes getContentLength() of HttpURLConnection Problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Sockets and Internet Protocols
Bookmark "getContentLength() of HttpURLConnection Problem" Watch "getContentLength() of HttpURLConnection Problem" New topic
Author

getContentLength() of HttpURLConnection Problem

John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937
I have the following code that works perfectly well under JDK 1.3 and below, but fails under JDK 1.4.1_01, when connection.getContentLength() returns -1. Does anyone have an explanation?
Thanks,
Eugene.


[ December 22, 2002: Message edited by: Eugene Kononov ]
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Maybe the precise behaviour of the class was changed. You are relying on getInputStream() performing an implicit connect() -- what happens if you connect() explicitly?
- Peter
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937
Peter,
I tried to connect() explicitely, but I got the same result, -- getContentLength() returns "-1" under JDK1.4.1_01, but valid length under JDK 1.3.1. I did some search outside JavaRanch and found a discussion thread about same exact problem, but it is in German. Here are a few quotes, can someone tell me if it solved the problem for the poster?
Thanks,
Eugene.

ich habs �berpr�ft, gleiches CGI, gleiche Sourcen.
Mit 1.4beta2 immer -1, sonst ein echter Wert.
Lesen bis nichts mehr drin ist hat nicht eklappt, aber in dem CGI gebe ich im Header jetzt ausdr�cklich die L�nge mit, damit funktioniert es.
Bei 1.3.1 wurde anscheinend erstmal in einen Buffer gelesen (ist nur kurzer Inhalt), bei 1.4beta2 ist das anscheinend nicht so.
Mal geraten: k�nnte es vielleicht sein, das 1.3 noch ein HTTP 1.0 verwendet hat und 1.4 nun HTTP 1.1 benutzt? Oder dass bei 1.3 kein Keep-Alive verwendet wird? Dann w�rde n�mlich die Verbindung nach dem senden der Daten abgebrochen, so dass die Gr�sse festgestellt werden kann. Bei HTTP 1.1 mit Keep-Alive ben�tigt man jedoch einen entsprechenden Eintrag im Header um die Gr�sse
des Bodys zu ermitteln.

Ohne es nachgesehen zu haben: 1.0 ist so veraltet, das ich mir das nicht vorstellen kann. Ausserdem hat das gar nichts mit der Problematik
zu zun.

Naja, wenn 1.4 HTTP 1.1 mit Keep-Alive verwendet und dort kein "Content-Length" Header mitgeliefert wird, dann k�nnte das sehr wohl zu
diesem Verhalten f�hren. Insoweit hat das schon was mit der Problematik zu
tun.
Tut es schon bei 1.0. Keep-Alive ist nur der Hinweis, das nicht bei jedem Request eine neue TCP-Connection aufgebaut werden soll, betrifft also eigentlich das darunterliegende Protokoll. Insofern k�nntest Du recht haben, dass nicht eigentlich HTTP, sondern schon die einfache TCP-Socket betroffen sein kann.
(Und das es da bei einigen Betriebssystemen Probleme geben kann ist ja bekannt)
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally quoted in German by Eugene Kononov:
I tried it, the same CGI, the same sources. With 1.4beta2 always -1, otherwise the real value.
Reading until it's finished didn't work, but at the moment I explicitly set the length in the CGI, that way it does work.
With 1.3.1 the contents were apparently first read into a buffer (they're only short), with 1.4beta2 this is apparently not the case.
Ah. Maybe this clarifies things a bit.
Note how getContentLength() returns -1 until he actuallys sets the Content-Length header. Actually this is the kind of behaviour you would expect in chunked HTTP 1.1 transfers. So how did JDK 1.3 manage to return the content length without the header?
I suddenly remember this thread, where it appears that J2SDK 1.3 buffers the entire contents of its output stream in memory, whereas J2SDK 1.4 appears to stream it the way you'd expect. If J2SDK 1.3 and 1.4 do the same for the input stream, it would explain why 1.3 can find out about the content length even if the header isn't set whereas 1.4 cannot.
This entry in the Bug Parade appears to be related to this -- the issue is perhaps a bit more subtle than I implied above but it may be basically correct.
If you have any control over the server, you may be able to set the Content-Length header. Otherwise, you'll have to read the contents into a buffer and find out the length that way.
- Peter
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937
Peter,
Thanks for not giving up on me. You would make a fine translator, among other things
Since I do not have control over the server (this is my online broker to wchich I connect over SSL), I followed your recommendation to use

instead of

This works under 1.3.1 and 1.4.1_01, as expected.
Thanks again,
Eugene.
rashmigupta maheshwarigupta
Greenhorn

Joined: Sep 16, 2010
Posts: 4
I am having similar code as posted in above thread. We are using java 1.1. Please let me know why am i getting content-length value null while getting length of input stream?

Also, can i use in.available in place of content-length value?

type of content from getInputStream is one or more xmls.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: getContentLength() of HttpURLConnection Problem