hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 37939] - Decouple control logic (expect-continue handshake, etc) from HttpClientConnection
Date Sat, 17 Dec 2005 14:26:14 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=37939>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37939





------- Additional Comments From olegk@apache.org  2005-12-17 15:26 -------
(In reply to comment #2)
> Hi Oleg,
> 
> yes, this looks good. Unfortunately I have to comment on the patch file
> itself, since I have not yet figured out how to apply patches. So please
> apologize if some of my observations are wrong.
> 

This is a nuisance. Actually it is dead-easy if you use Eclipse. If you are on
Linux is should be fairly easy with 'patch' utility. If you are on Windows
consider using Cygwin 


> 1. applications using HttpConnection directly will not be shielded from
>    1xx responses anymore. This is not really an issue, since well-behaved
>    servers will not send 1xx responses to standard requests without an
>    "Expect: continue" header.
> 

Agreed. Anyways, Http*Connection classes should be viewed as entities
representing _raw_ connections

> 1a. We could move the code for skipping 1xx responses from the request
>     executor into a static helper and call it from the ElementalPostRequest
>     example, too.
> 

ElementalPostRequest is after all an elemental POST. There's no need to create
helper classes for trivial sample apps. 

> 2. Will HttpClientConnection.readResponse(params) still be able to figure
>    out that the response to a HEAD request will not have an entity?
>    If not, we may have to extend the response strategy to accept a null
>    response as well as a null request. Then sendRequest could check for
>    the method and set a flag in the connection if the method/request does
>    not allow for a response entity. 
> 

Yes it will. HEAD method processing still needs work. It is on my list


> 3. I like the expect/continue logic being encapsulated in the request
>    executor. This will allow to use the same connection implementation
>    for synchronous and asynchronous communication.
> 

Cool

> cheers and thanks,
>   Roland

If there are no major objections, I'll go ahead and commit the patch. We can
still correct minor stuff with small incremental patches

Oleg

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Mime
View raw message