on 8/22/01 1:02 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have been spending the day on a bug I was getting in Cactus ... and it
> appeared the bug seems to be in HttpURLConnection under JDK 1.3 windows. It
> doesn't handle correctly the case when the server returns an empty response.
> It simply blocks, waiting for data ... It block for some servers (Resin,
> Tomcat 4, ...) and works for others (Tomcat 3.2, Orion 1.4, ...).
>
> The question is : what should I do ? I have imagined the following solutions
> :
>
> 1* Do nothing and simply warn users that their test cases need to return
> something (under JDK 1.3). I don't think it is practicable.
> 2* Manage to always send something back. Problem is it is difficult and a
> ugly hack. This is the solution I had until now but I don't like the hack :
> need to send a magic keyword on the server side and remove it on the client
> side so that the output stream can be asserted by the test case. Also, it
> prevents a lot of factorising as it means a different handling for JSPs than
> for servlets. And even for servlets, if the servlet does a forward, the
> server will raise an exception (which I was catching but still ulgy) ...
> 3* Use a replacement to Sun's HttpURLConnection. It is a pity because it is
> nice to use something standard and in any event, I'd like to go back to it
> once it is fixed (maybe JDK 1.4 ?). This is really where we are missing
> contributions from users for bug fixes at least (Sun would not accept them
> ... sigh). I hate to bring in another framework (i.e. another jar) and thus
> add some complexity and dependency. Solutions are : HTTPClient (it is a nice
> solution as it is supposed to be transparent by simply providing another
> provider for the HttpURLConnection abstract class by using
> the -Djava.protocol.handler.pkgs parameter. However, it does not work as it
> handles cookies differently for example and I would need to rewrite some
> part of the code. Too bad, that would have been a good solution I think).
> Another solution is commens httpclient (needs complete rewriting of the HTTP
> related code as it does not work as a protocol handler and I would hate to
> do that just to correct a bug of Sun).
> 4* Find another simple implementation of HttpURLConnection that I would
> include in the Cactus code (changing only the package). Not found so far ...
> I'll keep looking. I have found one but it was not handle sending POST
> parameters ...
> 5* Write my own one, just implementing what I need (by looking at commons
> httpclient). My fear is that it may be bigger than what I thought at first.
> For example, I'll need to support proxies and then someone will ask later on
> for HTTPS, ...
>
> I am a bit tired tonight and not sure what is best... I would like option 4
> but cannot find one. Would you know one ?
>
> Thanks a lot
> -Vincent
HttpURLConnection blows chunks. You have just hit *one* of its *many*
bugs...wait till you start trying to deal with multiple Set-Cookie (or any
multiple) headers with it...you can't...the stupid idiot who wrote it used a
Hashtable!
HTTPClient does work and I recommend it (even though it is very strangely
written)...it can do everything that you need, but you need to jump through
hoops and really study the API to make it do it...I used it for my
http://noodle.tigris.org/ project after tearing my hair out over
HttpURLConnection. However, we cannot accept it for use here in Jakarta land
as a dependency because it is LGPL.
-jon
