Weird HTTP header issue with PresentationServer 3.0 beta 2

> Hi,
>
> I have a weird issue with HTTP headers using PresentationServer 3.0 beta
> 2,
>
> I have uncommented the choose block that allows sending XHTML as
> application/xhtml+xml to clients that accept this media type in
> epilogue-servlet.xpl and, spuriously, a
>
> Content-Type: application/octet-stream;charset=utf-8
>
> header instead of the expected
>
> Content-Type: application/xhtml+xml;charset=utf-8
>
> This error seems more or less spurious and I have to reload several
> times the same page, playing with reload and shift reload before it
> happens.
>
> Note that when I add a debug attribute in the input of the HTTP
> serialization:
>
> <p:input name="data" href="#converted" debug="true"/>
>
> this weirdness disappears the header is always correct (I had to use
> tcpflow to trace it).
>
> Since this attribute disables caching, it is thus possible that this
> issue is related to the caching mechanism.
>
> Thanks,
>
> Eric

> Note that when I add a debug attribute in the input of the HTTP
> serialization:
>
> <p:input name="data" href="#converted" debug="true"/>
>
> this weirdness disappears the header is always correct (I had to use
> tcpflow to trace it).
>
> Since this attribute disables caching, it is thus possible that this
> issue is related to the caching mechanism.

> Eric van der Vlist wrote:
>
> > Note that when I add a debug attribute in the input of the HTTP
> > serialization:
> >
> > <p:input name="data" href="#converted" debug="true"/>
> >
> > this weirdness disappears the header is always correct (I had to use
> > tcpflow to trace it).
> >
> > Since this attribute disables caching, it is thus possible that this
> > issue is related to the caching mechanism.
>
> I didn't get this part of your message in the first reply.
>
> Yes, that's possible. However, in both cases (XHTML and HTML), there is
> a very similar path: oxf:qname-converter, then oxf:???-converter. The
> bug, if any, should be there in the HTML case as well!

> On jeu, 2005-09-01 at 13:35 -0700, Erik Bruchez wrote:
>
>>Eric van der Vlist wrote:
>>
>>
>>>Note that when I add a debug attribute in the input of the HTTP
>>>serialization:
>>>
>>><p:input name="data" href="#converted" debug="true"/>
>>>
>>>this weirdness disappears the header is always correct (I had to use
>>>tcpflow to trace it).
>>>
>>>Since this attribute disables caching, it is thus possible that this
>>>issue is related to the caching mechanism.
>>
>>I didn't get this part of your message in the first reply.
>>
>>Yes, that's possible. However, in both cases (XHTML and HTML), there is
>>a very similar path: oxf:qname-converter, then oxf:???-converter. The
>>bug, if any, should be there in the HTML case as well!
>
>
> Yes, I can confirm that it happens also in the HTML case.
>
> That's less spurious than I had thought and to reproduce it, I just need
> to press "shift+reload" twice after having removed the debug attribute
> on the http-serializer input:
>
>             <p:processor name="oxf:http-serializer">
>                 <p:input name="config">
>                     <config>
>                         <header>
>                             <name>Cache-Control</name>
>                             <value>post-check=0, pre-check=0</value>
>                         </header>
>                     </config>
>                 </p:input>
>                 <p:input name="data" href="#converted" debug="converted"/>
>             </p:processor>

> Erik Bruchez wrote:
>
> > It would be great if you had a simple reproduceable case. I can't see
> > this right now. What servlet engine are you using?
>
> Eric,
>
> I got the case by private email, thanks.
>
> I managed to reproduce it. That's a good catch! The reason this is
> happening is that you can optionally configure the serializer to use a
> local cache. In fact, this is the default setting. What this does is
> cause the serializer to store its output to the cache if possible.
>
> However, when replaying the data from the cache, no header information
> is set - hence the bug.
>
> We won't be able to fix this before our vacation, but it shouldn't be
> too hard to fix so I hope the fix can make it into 3.0 final.

> Erik Bruchez wrote:
>
> > I managed to reproduce it. That's a good catch! The reason this is
> > happening is that you can optionally configure the serializer to use a
> > local cache. In fact, this is the default setting. What this does is
> > cause the serializer to store its output to the cache if possible.
>
> Forgot to say that you can disable this by setting:
>
> <config>
>    ...
>    <cache-control>
>      <use-local-cache>false</use-local-cache>
>    </cache-control>
> </config>
>
> in the serialize configuration.

> On ven, 2005-09-02 at 18:07 -0700, Erik Bruchez wrote:
>> Erik Bruchez wrote:
>>
>>> It would be great if you had a simple reproduceable case. I can't see
>>> this right now. What servlet engine are you using?
>> Eric,
>>
>> I got the case by private email, thanks.
>>
>> I managed to reproduce it. That's a good catch! The reason this is
>> happening is that you can optionally configure the serializer to use a
>> local cache. In fact, this is the default setting. What this does is
>> cause the serializer to store its output to the cache if possible.
>>
>> However, when replaying the data from the cache, no header information
>> is set - hence the bug.
>>
>> We won't be able to fix this before our vacation, but it shouldn't be
>> too hard to fix so I hope the fix can make it into 3.0 final.
>
> No problem, I can live without cache in the meantime.
>
> Thanks and enjoy your vacation!