On Oct 29, 2012, at 12:02 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>
> On Oct 29, 2012, at 11:55 AM, Marek Potociar <marek.potociar_at_oracle.com> wrote:
>
>>
>> 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.
>
> Yes I know ... just saying :-) I felt that not making the remark and simply 'shutting up' isn't what I should do. Hence I wrote it :-)
>
>>
>>> 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?
>
> Geee .... that is my big problem currently: Finding complelling use cases for interceptors. I agree that the API is a good thing to have ... but telling people what to do with it that does not easily screw up the HTTP response (FRC 2616 wise) is kinda hard.
:) My problem is that I feel that the example conveys the information it is supposed to convey. If you don't think the example is good enough, you should provide a better one IMO.
>
> Right now, the best advice I would likely give others is 'don't use it' ... and that's not really very useful advice :-)
I would obviously disagree :)
It is still better to have the API than not to have it. JAX-RS API is not strictly about enforcing a correct HTTP behavior. While a reasonably smart user would know that using more advanced and powerful parts of the API has to be done with care and may perhaps even decide to not use it, another power-user that wants to implement a portable reusable feature component would use the API in a presumably correct way.
Marek
>
> Jan
>
>
>>
>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>