jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Altering response headers in a buffering writer interceptor

From: Jan Algermissen <jan.algermissen_at_nordsc.com>
Date: Wed, 7 Nov 2012 11:36:56 +0100

On Nov 7, 2012, at 11:34 AM, Marek Potociar <marek.potociar_at_oracle.com> wrote:

>
> On Nov 6, 2012, at 5:51 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>
>> One of the canonical examples for interceptors is to buffer the output stream, derive some form of value from it (e.g. in the digital signature case) and add that value to the response headers *before* streaming out the buffer.
>>
>> In order to make this work, there needs to be a guarantee that the runtime definitely waits for the first byte to arrive in the output stream before sending out the headers.
>>
>> While that is, to my knowledge, common practice in HTTP server software it is AFAIK an implementation choice. I cannot see JAX-RS runtime implementations to be required to behave like this. It would be perfectly valid to implement a runtime that sends the headers immediately, e.g. when <mbw>.getSize() returns -1.
>
> I believe there is such guarantee. At least I know that in Jersey we had to implement it that way. This implementation is implied by the design of MessageBodyWriter API methods. This is caused by the fact that MBW.writeTo(...) takes mutable headers and the javadoc states:
>
> * Write a type to an HTTP message. The message header map is mutable
> * but any changes must be made before writing to the output stream since
> * the headers will be flushed prior to writing the message body.
>
> So the guarantee you ask for is part of the spec IMO.

Agreed. Thanks.

Jan



>
> Marek
>
>>
>> Wouldn't it be a good idea to add to the spec a constraint to require the runtime to not send any response headers until the first byte hits the output stream?




>>
>> Jan
>