Re: using httpclient without a HttpClient object (was Redirects?)
On Monday, February 3, 2003, at 09:33 PM, Laura Werner wrote: Jeffrey Dever wrote: Is there anyone out there that has code that actually calls the HttpMethod.execute()? Anything that looks like this: HttpState state = new HttpState(); HttpConnection = new HttpConnection(host, port, secure); HttpMethod method = new GetMethod(path); int status = method.execute(state, connection); I do. I'm the one who doesn't use HttpClient at all, because it's too simplistic for me. I need to maintain a single HttpConnectionManager but a bunch of HttpState objects (one per thread in my application), so I have my own function that does the same thing as HttpClient.executeMethod. [ ... ] I would second the request to leave entry points into the `engine' behind HttpClient.java. As far as I understand it, HttpClient.java is just an implementation of a simple user agent. My expected use (and limited current use) of the API would likely not even mention HttpClient.java and would itself constitute a user-agent. To take the example of redirects, this is something I need control of (auto-redirects is the first thing I turn off in Sun's HttpURLConnection). -- Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: using httpclient without a HttpClient object (was Redirects?)
Jeffrey Dever wrote: Is there anyone out there that has code that actually calls the HttpMethod.execute()? Anything that looks like this: HttpState state = new HttpState(); HttpConnection = new HttpConnection(host, port, secure); HttpMethod method = new GetMethod(path); int status = method.execute(state, connection); I do. I'm the one who doesn't use HttpClient at all, because it's too simplistic for me. I need to maintain a single HttpConnectionManager but a bunch of HttpState objects (one per thread in my application), so I have my own function that does the same thing as HttpClient.executeMethod. The function looks something like execute(HttpMethod method, HttpState state, HttpConnectionManager connections). It lets HttpMethod.execute() handle intra-site redirects, but when it gets a 303 response back from that method, it takes care of the inter-site redirects without returning to the caller. I think it would be OK to add the redirect functionality to HttpClient, but I think it should go into a public static method, so that it can be called by the normal HttpClient methods and by people like me. I can do the work on this if you want. Laura Werner BeVocal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: using httpclient without a HttpClient object (was Redirects?)
Jandalf,
In contemplating your post, I had several thoughts:
* We should not remove functions from the APIs unless they are
already deprecated. To do otherwise will cause people to abandon
HttpClient (again!) as unstable. Rather, we should maintaining
deprecated functionality, with a good idea as to when it will be
removed.
* Instead of removing the execute() method, we might deprecate it
and add a sibling function called "executeWithoutRetry()" - OK,
that is a bad name, but you hopefully get the idea.
* I believe strongly in exposing interfaces, rather than instances,
something HttpClient could do more of. If you take that approach,
though, you can make the interfaces public, but the
implementations package access, thus discouraging certain uses
without actually preventing them. In other words, if a client can
figure out how to correctly implement the "HttpConnectionIntf"
interface, you are welcome to do so (at your own risk), and call
HttpMethod.execute() directly.
* I couldn't decide whether the "redirect" functionality is
something that should be "pushed down" or "pulled up". Is is
something that HttpMethodBase delegates to another class to do for
it, or is HttpMethodBase considered "dumb", and not responsible
for retries, but instead relies on its caller to do for it? This
would speak to the need to deprecate the execute method at all.
I agree that it certainly isn't too late to add this change, but am
strongly in favor of designing in such a way as to maintain compatibility.
-Eric.
Jeffrey Dever wrote:
Is there anyone out there that has code that actually calls the
HttpMethod.execute()? Anything that looks like this:
HttpState state = new HttpState();
HttpConnection = new HttpConnection(host, port, secure);
HttpMethod method = new GetMethod(path);
int status = method.execute(state, connection);
As opposed to this:
HttpClient client = new HttpClient();
HttpMethod method = new
GetMethod("http://jakarta.apache.org/commons/httpclient/";);
int status = client.executeMethod(method);
Anyone that is using the httpclient package without ever instantiating
a HttpClient object, speak now, or forever hold your peace. If we
want to do redirects right, simplify the monolithic HttpMethod, then
we are talking about the possibility of removing HttpConnection and
HttpMethod.execute() from the public interface, and your code will break.
If nobody actually uses HttpClient like this, and have compelling
reasons for it, then I don't think this is too late to add this
important functionality.
Oleg Kalnichevski wrote:
Jandalf,
I believe it's not just about redirects. All the retrial stuff as well
as (most likely) buffering should not be part of HttpMethodBase. It
would require quite a bit of change. I am all for it, but that's would
spell quite a bit of change in just beginning to stabilize HttpClient's
Middle Earth. What's your call?
Oleg
On Mon, 2003-02-03 at 21:17, Jeffrey Dever wrote:
Right, we should go back to the HttpClient to get another
HttpConnection. Perhaps the entire redirect mechanism should be
pushed up to the HttpClient class. I never liked the idea of a
user holding onto a HttpState, HttpMethod and HttpConnection and
calling the execute() method itself. This use is what forces the
HttpMethodBase to be so large.
I don't see this as being a huge job. At some point it has to be
done. The question is, wether it is 2.0 or 2.1 content.
Ortwin Glück wrote:
Alan Marcinkowski wrote:
I found HttpMethodBase:checkValidRedirect was not honoring cross
server redirects. Isn't this a common type of redirect? Is there
a reason its not supported? [...] unless its an architectural
issue [...]
Alan,
unfortunately that is an architectural issue currently. Each
HttpClient is bound to a specific host and a method can not change
this since a method has no knowledge about its calling HttpClient
instance (if any). Moreover the code responsible for handling the
response is contained inside the methods. But most of it should be
moved to the HttpClient actually in the future. Sorry for this
limitation.
Odi
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To
Re: using httpclient without a HttpClient object (was Redirects?)
Jeffrey Dever wrote: If we want to do redirects right, simplify the monolithic HttpMethod, then we are talking about the possibility of removing HttpConnection and HttpMethod.execute() from the public interface, and your code will break. What exactly is the use case for this? I am working on a fairly sophisticated integration of HttpClient with XML-RPC, and have not found a need for this yet. Admittedly I haven't started on the asynchronous/multithreaded integration yet, so perhaps that's where its useful. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
using httpclient without a HttpClient object (was Redirects?)
Is there anyone out there that has code that actually calls the
HttpMethod.execute()? Anything that looks like this:
HttpState state = new HttpState();
HttpConnection = new HttpConnection(host, port, secure);
HttpMethod method = new GetMethod(path);
int status = method.execute(state, connection);
As opposed to this:
HttpClient client = new HttpClient();
HttpMethod method = new
GetMethod("http://jakarta.apache.org/commons/httpclient/";);
int status = client.executeMethod(method);
Anyone that is using the httpclient package without ever instantiating a
HttpClient object, speak now, or forever hold your peace. If we want to
do redirects right, simplify the monolithic HttpMethod, then we are
talking about the possibility of removing HttpConnection and
HttpMethod.execute() from the public interface, and your code will break.
If nobody actually uses HttpClient like this, and have compelling
reasons for it, then I don't think this is too late to add this
important functionality.
Oleg Kalnichevski wrote:
Jandalf,
I believe it's not just about redirects. All the retrial stuff as well
as (most likely) buffering should not be part of HttpMethodBase. It
would require quite a bit of change. I am all for it, but that's would
spell quite a bit of change in just beginning to stabilize HttpClient's
Middle Earth. What's your call?
Oleg
On Mon, 2003-02-03 at 21:17, Jeffrey Dever wrote:
Right, we should go back to the HttpClient to get another
HttpConnection. Perhaps the entire redirect mechanism should be pushed
up to the HttpClient class. I never liked the idea of a user holding
onto a HttpState, HttpMethod and HttpConnection and calling the
execute() method itself. This use is what forces the HttpMethodBase to
be so large.
I don't see this as being a huge job. At some point it has to be done.
The question is, wether it is 2.0 or 2.1 content.
Ortwin Glück wrote:
Alan Marcinkowski wrote:
I found HttpMethodBase:checkValidRedirect was not honoring cross
server redirects. Isn't this a common type of redirect? Is there a
reason its not supported? [...] unless its an architectural issue [...]
Alan,
unfortunately that is an architectural issue currently. Each
HttpClient is bound to a specific host and a method can not change
this since a method has no knowledge about its calling HttpClient
instance (if any). Moreover the code responsible for handling the
response is contained inside the methods. But most of it should be
moved to the HttpClient actually in the future. Sorry for this limitation.
Odi
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
