Re: 202

Replies inline

paul.downey@bt.com wrote:

>David 
>
>  
>
>>Suppose, for example, that I'm using some sort of reliability mechanism
>>to ensure that a series of one-way messages arrives safely.  Why would I
>>be using that with HTTP, which sits on top of TCP?  The series of
>>one-way messages spans any particular connection.  Even TCP can drop a
>>connection, and the receiver might have successfully received a message
>>but been unable to return any kind of response.  In such a case, it
>>could well be useful to acknowledge that message on receipt of the next
>>message, hoping to avoid a needless retransmit.
>>    
>>
>
>I don't think I fully understand this paragraph: is it saying that a TCP 
>connection may fail after the reciever has received the complete HTTP 
>request, but before sending an HTTP ACK? 
>
>In which case both sender and receiver are aware that the connection has 
>broken and without the HTTP ACK and the TCP shutdown three-way handshake 
>the sender must assume that the message hasn't been 'secured', let alone 
>processed. I'm not sure how this relates to HTTP 202 though.
>  
>
The actual question is whether, when a message goes one-way over HTTP,
the sender and receiver can disagree as to whether it arrived
successfully.  I agree that, since HTTP sits on TCP, it's hard to come
up with scenarios where this would happen.  Nonetheless, I'm not sure
that we haven't missed some scenario out.

>  
>
>>Or, suppose that the receiver wants to send a one-way message to the
>>sender, possibly for some unrelated reason.  The response channel is
>>there.  Why not use the bandwidth?  This could be particularly important
>>in situations where connections are relatively expensive, perhaps in
>>mobile applications.
>>    
>>
>
>You want to treat a HTTP conversation as a bi-directional pipe? 
>Out of  interest, which SOAP specifications do this, and do we want
>to consider existing or potential specs which abuse HTTP in this way?
>  
>
AFAICT, PAOS doesn't quite do this, but it comes close:

    * App-level server sends HTTP server a special request.
    * App-level client sends app-level request as HTTP response.
    * App-level server sends app-level response as HTTP POST request.
    * App-level client sends, erm, something back.

If that "something" is another app-level request -- and I honestly don't
see why it couldn't be -- then you have a bidirectional pipe.  Even if
it's not, this seems no more or less HTTP-abusive than what I
mentioned.  Indeed, it was my starting point. 

Perhaps this is all better viewed as a tunneling mechanism.  From the
point of view of some proxy in the middle that doesn't know what's going
on, it should look like ordinary requests and responses going back and
forth.

>  
>
>>I've argued elsewhere that, for other reasons, an acknowledgment message
>>might want to contain WSA headers, but I forget whether that would only
>>apply to asynchronous bidirectional transports.
>>    
>>
>
>Sorry, but I need some more context here than 'elsewhere' to understand
>this sentence!
>  
>
It's probably not relevant, but the particular case was using a SOAP
message as an acknowledgment, so that this message could include
relevant information in SOAP headers, e.g., a message ID ("I'm
acknowledging this particular message").  This doesn't really apply to
HTTP where you already know what you're acknowledging, but it would
apply if you have a bidirectional asynchronous pipe.  However, I'm not
completely convinced that there will never be a need for non-trivial
acknowledgment information.

>  
>
>>In any case, it seems fine to make a general rule -- independent of any
>>particular concept of a MEP -- that when the receiver of an HTTP
>>response has nothing else to send back, it should send back a 202
>>(rather than, say, simply dropping the connection).  This seems pretty
>>well in line with the intent of 202.  
>>    
>>
>
>I'm not sure about the 'general rule', but I believe that's what we 
>have documented in the Test Suite:
>
>http://www.w3.org/2002/ws/addr/testsuite/exchanges/
>  
>
Right, but that's not normative (or at least, it has no official
standing :-).

>  
>
>>But it may well be too restrictive
>>to mandate that the receiver MUST send back a 202 with an empty SOAP
>>body in cases where it is effectively receiving a one-way message.
>>    
>>
>
>Er, AIUI RFC2616 encourages a 202 to contain stuff such as estimates 
>of how long the *request* can be completed, status information for the 
>*request* and  a link to where the status of the *request* can be 
>monitored. 
>  
>
So this seems to argue against mandating an empty SOAP message as
content.  Or am I missing something?

>Anything else wonders back into HTTP abuse territory.
>
>Paul
>
>
>  
>