hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Johnson <e...@tibco.com>
Subject Re: using httpclient without a HttpClient object (was Redirects?)
Date Mon, 03 Feb 2003 21:13:22 GMT
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: 
>>>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: 
>>>> commons-httpclient-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>     
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: 
>>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: 
>>> commons-httpclient-dev-help@jakarta.apache.org
>>>
>>>   
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: 
>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: 
>> commons-httpclient-dev-help@jakarta.apache.org
>>
>>
>>  
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org
>


Mime
View raw message