On Oct 29, 2012, at 8:30 AM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>
> On Oct 27, 2012, at 4:41 PM, Marek Potociar <marek.potociar_at_oracle.com> wrote:
>
>> The examples in the spec illustrate JAX-RS APIs not any particular feature implemented with these APIs. So I think we should keep the examples simplistic in the spec. The features you're talking about will be most likely provided by more skilled developers anyway.
>
> After mulling this over, I disagree. The examples also bother to show finishing the gzip OS and restoring the original OS.
Examples are not normative part of the spec AFAIK.
> However, as it stands, the example will definitely produce incorrect behavior from an HTTP POV.
>
> You could equally well assume that the 'more skilled developers' will know to finish and restore the streams.
>
> Personally, I think th eexample fails to illustrate the point that messing with the output stream will, in many cases, require an update to the HTTP headers to maintain HTTP message correctness. There should either be a note or it should be an example that yields a correct HTTP response.
Can you suggest a concrete comparably simple example that will be more explanatory and HTTP-wise correct which we could use to replace the current example?
Thanks,
Marek
>
> Jan
>
>>
>> Marek
>>
>> On Oct 26, 2012, at 10:59 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>>
>>> Hi,
>>>
>>> Section 4.2.6 correctly says:
>>>
>>> "Content encoding is the responsibility of the application. Application-supplied entity providers MAY per- form such encoding and manipulate the HTTP headers accordingly."
>>>
>>> Section 6.3 then provides the gzip example for writer interceptors but does not set the corresponding HTTP header. It also does not modify the ETag header, should one be present.
>>>
>>> The later I am currently checking up on, but I am currently quite convinced the Etag should be modified to achieve correct cache behavior.
>>>
>>> Bothe (or at least the former) cases should IMHO be shown or at least noted as a comment, e.g. // ...adjust Content-Encoding and ETag response headers.
>>>
>>> As it stands the example can be quite misleading to developers without deep interest in HTTP mechanics (that is almost all developers).
>>>
>>> Thoughts?
>>>
>>> Jan
>>>
>>>
>>
>