commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: [httpclient] question
Date Mon, 13 Oct 2003 03:27:23 GMT
Hi Denis,

Both of these options are supported by HttpClient.  To handle 100 
continue responses the request must be either a POST or a PUT as 100 
continue is only valid on methods that contain bodies.  This option 
will also need to be enabled by calling setUseExpectHeader(true) on the 
POST/PUT method.  The redirects are also a valid option, the only 
caveat here is that HttpClient limits to 100 the number of redirects 
that a method will take.

Enjoy,

Mike

On Sunday, October 12, 2003, at 09:59 PM, Denis Haskin wrote:

> This may be a naive suggestion, but I can think of two possibilities 
> here that *sort* of get around the "1 request, 2 responses".
>
> First, there is the HTTP 100 Continue response.  This is pretty much 
> exactly what the original poster said: "2) server returns confirmation 
> response: I've just got your request and going to process it. Standby! 
> (no problem)".
>
> See [1] and [2] for discussion.  Theoretically a server can keep 
> sending 100 Continue responses as long as it wants until it's ready to 
> send the actual response, which it then sends with a 200 OK (although 
> I'm not sure how timeouts work in this case).
>
> Also, I have seen systems where this is accomplished using HTTP 
> redirects (302 or 307, I think)--client sends request, server replies 
> with a redirect and starts processing the request, client goes to the 
> redirect address, at which the server can then provide the response.  
> Again, this can also be done with a sort of "looping" redirect which 
> keeps happening until the result is ready.
>
> Neither of these are esoteric; I've used them in many situations.
>
> As other posters have said, though, there's *no* *way* in HTTP you're 
> going to be able to have the server notify the client.  It's just not 
> part of the protocol.
>
> dwh
>
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.1.1
> [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3
>
>
> Oleg Kalnichevski wrote:
>
>>> Hello Oleg!
>>>
>>> I've reinvestigated the problem and found that you're right. The 
>>> response is being returned,
>>> but my problem still remains :(
>>>
>>> How should I implement the following using HttpClient?
>>>
>>> 1) send a business-request to server (no problem)
>>> 2) server returns confirmation response: I've just got your request 
>>> and going to process it. Standby! (no problem)
>>> 3) server processes that request and _notifies_ the client: Done 
>>> processing successfully. (that's where I've stuck. The old 
>>> implementation I try to get rid of uses some kind of socket observer 
>>> which queries the socket from time to time and finally gets the 
>>> server notification. Is this doable using HttpClient?)
>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>


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


Mime
View raw message