Servlet session tracking problems with IE5 and MPEG files

[Gilles Kuhn]

I'm developing a servlet application (with TOMCAT) which publishes
various type of files includind MPEG. When I click an hyperlink to a
MPEG file, a download error occurs in IE5. After hours spent on trying
to modify HTTP headers, without any success, I realized that IE opens
Windows Media Player, which download the mpeg file, but in this case,
it opens a new servlet session (new session cookies, so there is no
link anymore to the actual session in which the user is logged in). As
a result, the request is rejected, because the user is not logged in
the session.
This problem happens only with IE5 (not in IE6 nor Mozilla), and only
with WMP. Even with word or pdf files which requires external plugins
just like MPEG files it works well.
Has anyone an great idea to preserve session tracking continuity in
this case?
Thanks in advance.

ps: my configuration is:
IE 5.00
Windows Media Player 6.4.09.1121
Tomcat 4.1.18

ps2: If ever other people are faced with the same problem, I have a
temporary workaround based on HTTP header setting:
HttpServletResponse.setHeader("Content-Disposition", "attachment;
filename=video.mpg");
With this there is no error anymore, it keeps the same session, but
you have to click twice to agree for download.

--------------------------------------------------------------
Gilles Kuhn, software engineer
KUHN ORGANISATION
4, rue Hannong 67380 Lingolsheim
tél: +33 3 88 76 54 44
fax: +33 3 88 76 90 07
http://www.kuhnorga.com
--------------------------------------------------------------

 

[Ben_]

Possible approaches:
* live with the two prompts
* search the MSDN-Technet @ MS to know if it is a known bug (could be IE or
WMP) and put this as requirement to your app
* turn session tracking from cookie to URL-rewriting (but this may not be as
transparent to your app as it sounds)

 

[Jeff Kish]

Possible approaches:
* live with the two prompts
* search the MSDN-Technet @ MS to know if it is a known bug (could be IE or
WMP) and put this as requirement to your app
* turn session tracking from cookie to URL-rewriting (but this may not be as
transparent to your app as it sounds)

I don't know much about these things, but if you can
detect the level of i.e. then you could warn them
about the two prompts in the case of i.e. 5, and not do so in the
other cases. Since i.e. 5 is pretty old,
(security minded folks would of upgraded)
maybe this would be a small exposure?
HTH,
Jeff Kish

 

[Andrew Thompson]

I don't know much about these things, but if you can
detect the level of i.e. then you could warn them
about the two prompts in the case of i.e. 5, and not do so in the
other cases. Since i.e. 5 is pretty old...

As I understand it, IE 5 (for the Mac) is not
that old, it is also a completely different app.
to IE 5 (Windoze). One of the many dangers
of relying on browser sniffing (if that is what you
were suggesting).

I have lost the start of this thread, but just wanted
to check someone had suggested a message to all
surfers "If this page appears strange, try the
alternate version at..."


If 'browser-sniffing' is the answer, it must have
been a stupid question. ;-)