> Thanks. It is what I wanted to heard.
>
Haha, from my side I tried to avoid going to Atmosphere code, just
wanted to show what's happening in general.
> Should we do a blog about that? Maybe others could had a similar
> problem.(rare cases).
>
You mean blog about default content-types in Grizzly and how they are
being applied?
WBR,
Alexey.
>
>> On Apr 26, 2010 9:03 AM, "Oleksiy Stashok"
>> <Oleksiy.Stashok_at_sun.com> wrote:
>>
>> > OK cool, so can you trace the code to see what going on?
>>
>> Yes, I've even described what I see :)) There is no change in code
>> path, except one, which is called just once.
>> It happens *before* login, when browser's script initializes async
>> atmosphere connection. Atmosphere doesn't set Content-Type header
>> for the HTTP response, see AtmosphereResourceImpl.write(), so the
>> Content-Type header is null, and in this case Grizzly sets the
>> default one.
>>
>> Otherwise there is no login/post or any other issues with the
>> applications. In the wireshark I see those messages are sending/
>> coming absolutely the same way as before.
>>
>> IMO, either browser or specific java script doesn't accept content-
>> type header for the Atmosphere async. HTTP connection.
>>
>> The simple fix for Atmosphere (in order to make it work on Grizzly)
>> is to add following line into AtmosphereResourceImpl.write():
>>
>> **********
>> void write() {
>> // Set to expire far in the past.
>> res.setHeader("Expires", "-1");
>> // Set standard HTTP/1.1 no-cache headers.
>> res.setHeader("Cache-Control", "no-store, no-cache, must-
>> revalidate");
>> // Set standard HTTP/1.0 no-cache header.
>> res.setHeader("Pragma", "no-cache");
>> ++++ res.setHeader("Content-Type", ""); <-------------
>> This one
>> ***********
>>
>> May be it's possible to fix this directly on the client side, don't
>> know.
>>
>> WBR,
>> Alexey.
>>
>>
>> >
>> >> On Apr 26, 2010 7:06 AM, "Oleksiy Stashok" <Oleksiy.Stashok_at_sun.com
>> > wrote:
>> >>
>> >> Sebastien,
>> ...
>>
>