Marc Hadley wrote:
> We also need to support "one-way" in the opposite direction using
> HTTP GET (no message out but message in from the client perspective)
> and using the XML/HTTP binding its going to be important to be able
> to set/get HTTP headers for an empty request and to set/get HTTP
> response headers in an empty response.
OK. Thanks for the input.
>
> I thought all of the HTTP stuff went into the message context and I'd
> expect that to be around regardless of whether there's a HTTP payload
> or not ?
>
> Marc.
>
> On Jan 31, 2006, at 7:45 PM, Kohsuke Kawaguchi wrote:
>
>>
>> Hi Roberto and Marc,
>>
>> Kathy and Jitu pointed out that when an user is making an one-way
>> invocation, he should nevertheless see the response HTTP headers,
>> HTTP status code, and other information through ResponseContext.
>>
>> This turns out to be a problem with the renewed architecture, since
>> internally it's built around the notion of sending/receiving
>> messages --- so without a reply "message", it doesn't have a place
>> to put those information so that it gets carried from the transport
>> to the stub.
>>
>> The obvious way to fix it is to introduce a "message
>> envelope" (don't confuse this with SOAP envelope) that has an
>> optional message in it, and use the envelope to keep the related
>> information around. In this model, I'd be creating an envelope
>> without a message, but just with envelope information like HTTP
>> headers.
>>
>> But for a few reasons, I'm reluctant to make changes.
>>
>> - it's a considerable change. It can be done, but it's something I'd
>> like to avoid if possible, because it affects all the Tango people.
>>
>> - I found it conceptually bit strange that one-way transport needs to
>> return some information back to the client (especially when the
>> "real" reply might come back on another communication channel
>> later.)
>> I thought one-way is one-way; no information coming back.
>>
>> There are a few hacks to make it work without introducing a
>> considerable change, but I'd like to investigate what my options
>> are first. Hence this e-mail.
>>
>> Do you think clients should see HTTP response information on one-
>> way invocations? On more generally speaking, when the transport is
>> used as one-way, should it yield any data upon a successful
>> completion (if it fails to send a message, then all sorts of
>> information would be coming back, for sure.)
>>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems kohsuke.kawaguchi_at_sun.com
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
>
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com