hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kalnichevski, Oleg" <oleg.kalnichev...@bearingpoint.com>
Subject RE: Proxy problems
Date Thu, 05 Dec 2002 16:39:47 GMT
Chris,

My concern is that HttpMethodBase is getting really unwieldy. HTTP PUT and POST have a lot
of commonalities. I believe it would be more appropriate to derive both PostMethod and PutMethod
from a common super class (derived in its turn form HttpMethodBase) which would encapsulate
Expect Continue case as well as other common functionality. I have been long (well, even since
I have been around) petitioning for a thorough revision of HttpMethodBase which would result
in a better, more modular structure. The idea has been turned down, though, until version
2 release at least. 

Oleg

-----Original Message-----
From: Chris Smith [mailto:cdsmith@twu.net]
Sent: Thursday, December 05, 2002 17:03
To: Jakarta Commons: HttpClient Dev
Subject: Proxy problems


I appear to have gotten PUT through a proxy working, sorta...  I've attached
a subclass of the PUT method that does not expect a 100-continue, so will
work through most proxy servers.

I'm willing, if you guys think it's a good idea, to put together a patch
that moves this option into HttpMethodBase, and add support for the expect
to the POST method as well, so that anything with a request body can be set
to either send it immediately, or wait for 100-continue first.  That would
involve two additional methods in HttpMethodBase:

    public void setExpectingContinue(boolean v);
    public boolean isExpectingContinue();

These methods would have no effect for HEAD, GET, and the like.


I'd also like to consider doing a more elaborate patch for some more subtle
problems with connection and status handling, which may or may not be
limited to proxies.  I'd like someone to say they think the goal is a good
idea before I continue, though.  Some specific issues:

1. If the output stream is closed from the remote side while sending the
request body, HttpClient throws a SocketException.  Instead, it should
attempt to read a response, and return the status there.  I'm specifically
seeing a proxy prematurely close the connection and respond with a 413
(Request Entity Too Large) -- that behavior makes sense, and I'd like to get
the 413 back instead of a SocketException.

2. Instead of just the 100-continue fix above, we should comply with the
HTTP spec section that I posted earlier -- that means only waiting a certain
amount of time, not indefinitely, to receive the 100-continue before
continuing.  Then, when a proxy or the remote server doesn't understand that
expectation, the request is merely delayed... not prevented.  We probably
ought to pick a default delay based on the time required to establish the
connection to the server.

Both of those two seem connected.  They both involve handling input and
output streams from the socket separately.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Mime
View raw message