Strange error while doing redirects in Jetty 5.1.3

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange error while doing redirects in Jetty 5.1.3

Alex Savitsky
I was trying some black magic with Spring/Tapestry, and at one moment, I needed
to execute a redirect twice (using the HttpServletResponse.sendRedirect()).
After the second redirect, here's what I've got in stack trace:
 
java.io.IOException: The filename, directory name, or volume label syntax is
incorrect
        at java.io.WinNTFileSystem.canonicalize0(Native Method)
        at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:395)
        at java.io.File.getCanonicalPath(File.java:531)
        at org.mortbay.util.FileResource.getAlias(FileResource.java:162)
        at org.mortbay.http.ResourceCache.getResource(ResourceCache.java:252)
        at org.mortbay.http.HttpContext.getResource(HttpContext.java:2135)
        at org.mortbay.jetty.servlet.WebApplicationContext.getResource
(WebApplicationContext.java:775)
        at org.mortbay.jetty.servlet.Default.getResource(Default.java:185)
        at org.mortbay.jetty.servlet.Default.service(Default.java:209)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:427)
        at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch
(WebApplicationHandler.java:475)
        at org.mortbay.jetty.servlet.ServletHandler.handle
(ServletHandler.java:556)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1563)
        at org.mortbay.jetty.servlet.WebApplicationContext.handle
(WebApplicationContext.java:623)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1515)
        at org.mortbay.jetty.plus.PlusWebAppContext.handle
(PlusWebAppContext.java:158)
        at org.mortbay.http.HttpServer.service(HttpServer.java:956)
        at org.mortbay.http.HttpConnection.service(HttpConnection.java:814)
        at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981)
        at org.mortbay.http.HttpConnection.handle(HttpConnection.java:831)
        at org.mortbay.http.SocketListener.handleConnection
(SocketListener.java:244)
        at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
        at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
WARN - Alias request of 'file:/C:/Personal/Java/workspace/SimpleApp/context/B%
C2%8E%15Áçi%C2%99%C2%9A%13â¦%C2%92óÝX²%12%1A%0BA¥s׸%C2%9F%C2%9B%01t%C2%8BÏ5%03

I'm not sure whether mail would be able to reproduce the exact sequence of
garbage in the last line (the one with "WARN - Alias request of" in the
beginning), but I'll put it here anyway.

Strangely enough, the application itself behaved as if nothing happened - no
exceptions thrown, it simply didn't load the page. sendRedirect() didn't report
anything, either.

What's even more strange - when I use Mozilla FireFox, I cannot get this
problem - only if I'm using IE6 (v.6.0.2800.1106 if it matters). Now, I know, I
know - "Micro$oft suxx" - but my user base wouldn't take that as an
explanation, unfortunately :(

So, had anybody seen anything like that? Any ideas?

Thanks in advance,

Alex



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Strange error while doing redirects in Jetty 5.1.3

Chris Haynes
Well, it appears as if at some stage something has presented a load of non-ASCII
characters to a browser, and it has used %HH encoding on it.  What's curious is
that it seems to have encoded some non-ASCII values 'properly' using the %HH
notation, but has let through others which are plainly not (7-bit) ASCII.

Presumably you know what the 'correct' file names in
    C:/Personal/Java/workspace/SimpleApp/context/
are.

I hope there are only 7-bit ASCII characters in these  names.  Redirect uses an
HTTP header for which there is no 'official' support for non-ASCII characters.
If you are giving it a URL with non-ASCII characters there will _always_ be
uncertainty as to what will happen.

If you _have_ to have non-ASCII characters in the URL I would recommend one of
two approaches:

1) encode them yourself using a 'private' encoding which you remove when the
request comes back,

2) put the file name into the query part opf the URL (after a ?) and use
URL-encoding on it before you send it - you convert all non-ASCII characters
into %HH triplets, so that the URL you ask it to forward to would look something
like

http://site/servlet?f=B%C2%8E%15

Then, rather messily, you would have to cope with turning this into a resource
look-up on reception.

Non-ASCII characters in URLs are to be avoided at all costs!

Chris Haynes


"Alex Savitsky" asked:


I was trying some black magic with Spring/Tapestry, and at one moment, I needed
to execute a redirect twice (using the HttpServletResponse.sendRedirect()).
After the second redirect, here's what I've got in stack trace:

java.io.IOException: The filename, directory name, or volume label syntax is
incorrect
at java.io.WinNTFileSystem.canonicalize0(Native Method)
at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:395)
at java.io.File.getCanonicalPath(File.java:531)
at org.mortbay.util.FileResource.getAlias(FileResource.java:162)
at org.mortbay.http.ResourceCache.getResource(ResourceCache.java:252)
at org.mortbay.http.HttpContext.getResource(HttpContext.java:2135)
at org.mortbay.jetty.servlet.WebApplicationContext.getResource
(WebApplicationContext.java:775)
at org.mortbay.jetty.servlet.Default.getResource(Default.java:185)
at org.mortbay.jetty.servlet.Default.service(Default.java:209)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:427)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch
(WebApplicationHandler.java:475)
at org.mortbay.jetty.servlet.ServletHandler.handle
(ServletHandler.java:556)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1563)
at org.mortbay.jetty.servlet.WebApplicationContext.handle
(WebApplicationContext.java:623)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1515)
at org.mortbay.jetty.plus.PlusWebAppContext.handle
(PlusWebAppContext.java:158)
at org.mortbay.http.HttpServer.service(HttpServer.java:956)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:814)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:831)
at org.mortbay.http.SocketListener.handleConnection
(SocketListener.java:244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
WARN - Alias request of 'file:/C:/Personal/Java/workspace/SimpleApp/context/B%
C2%8E%15Áçi%C2%99%C2%9A%13â¦%C2%92óÝX²%12%1A%0BA¥s׸%C2%9F%C2%9B%01t%C2%8BÏ5%03

I'm not sure whether mail would be able to reproduce the exact sequence of
garbage in the last line (the one with "WARN - Alias request of" in the
beginning), but I'll put it here anyway.

Strangely enough, the application itself behaved as if nothing happened - no
exceptions thrown, it simply didn't load the page. sendRedirect() didn't report
anything, either.

What's even more strange - when I use Mozilla FireFox, I cannot get this
problem - only if I'm using IE6 (v.6.0.2800.1106 if it matters). Now, I know, I
know - "Micro$oft suxx" - but my user base wouldn't take that as an
explanation, unfortunately :(

So, had anybody seen anything like that? Any ideas?

Thanks in advance,

Alex



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support





-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Strange error while doing redirects in Jetty 5.1.3

Alex Savitsky
> Chris Haynes <chris <at> harvington.org.uk> writes:

>
> Well, it appears as if at some stage something has presented a load of non-
ASCII
> characters to a browser, and it has used %HH encoding on it.  What's curious
is
> that it seems to have encoded some non-ASCII values 'properly' using the %HH
> notation, but has let through others which are plainly not (7-bit) ASCII.
>
> Presumably you know what the 'correct' file names in
>     C:/Personal/Java/workspace/SimpleApp/context/
> are.
>
> I hope there are only 7-bit ASCII characters in these  names.  Redirect uses
an
> HTTP header for which there is no 'official' support for non-ASCII
characters.
> If you are giving it a URL with non-ASCII characters there will _always_ be
> uncertainty as to what will happen.
>
> If you _have_ to have non-ASCII characters in the URL I would recommend one
of
> two approaches:
>
> 1) encode them yourself using a 'private' encoding which you remove when the
> request comes back,
>
> 2) put the file name into the query part opf the URL (after a ?) and use
> URL-encoding on it before you send it - you convert all non-ASCII characters
> into %HH triplets, so that the URL you ask it to forward to would look
something
> like
>
> http://site/servlet?f=B%C2%8E%15
>
> Then, rather messily, you would have to cope with turning this into a
resource
> look-up on reception.
>
> Non-ASCII characters in URLs are to be avoided at all costs!
>
> Chris Haynes
>
> "Alex Savitsky" asked:
>
> I was trying some black magic with Spring/Tapestry, and at one moment, I
needed

> to execute a redirect twice (using the HttpServletResponse.sendRedirect()).
> After the second redirect, here's what I've got in stack trace:
>
> java.io.IOException: The filename, directory name, or volume label syntax is
> incorrect
> at java.io.WinNTFileSystem.canonicalize0(Native Method)
> at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:395)
> at java.io.File.getCanonicalPath(File.java:531)
> at org.mortbay.util.FileResource.getAlias(FileResource.java:162)
> at org.mortbay.http.ResourceCache.getResource(ResourceCache.java:252)
> at org.mortbay.http.HttpContext.getResource(HttpContext.java:2135)
> at org.mortbay.jetty.servlet.WebApplicationContext.getResource
> (WebApplicationContext.java:775)
> at org.mortbay.jetty.servlet.Default.getResource(Default.java:185)
> at org.mortbay.jetty.servlet.Default.service(Default.java:209)
> << pruned >>
> WARN - Alias request of 'file:/C:/Personal/Java/workspace/SimpleApp/context/B%
> C2%8E%15Áçi%C2%99%C2%9A%13â¦%C2%92óÝX²%12%1A%0BA¥s׸%C2%9F%C2%9B%01t%C2%8BÏ5%
03
>
> I'm not sure whether mail would be able to reproduce the exact sequence of
> garbage in the last line (the one with "WARN - Alias request of" in the
> beginning), but I'll put it here anyway.
>
> Strangely enough, the application itself behaved as if nothing happened - no
> exceptions thrown, it simply didn't load the page. sendRedirect() didn't
report
> anything, either.
>
> What's even more strange - when I use Mozilla FireFox, I cannot get this
> problem - only if I'm using IE6 (v.6.0.2800.1106 if it matters). Now, I know,
I
> know - "Micro$oft suxx" - but my user base wouldn't take that as an
> explanation, unfortunately :(
>
> So, had anybody seen anything like that? Any ideas?
>
> Thanks in advance,
>
> Alex
>

The thing is - if something had introduced these garbage characters into the
URL, it's anything but my app. All my files are 7-bit ASCII, I haven't been
playing with the localizations yet, and I checked my project folder again just
to be sure Eclipse haven't introduced any funny stuff in there (it haven't).
BTW, the characters appeared unencoded in my exception trace, they got encoded
to %NN form when I posted them to mail list.

I tried to trace the problem, got all the way down to
org.mortbay.http.HttpRequest.readHeader() - it doesn't look like something
introduced into URL, after all. Apparently it gets all this garbage in the
LineInput buffer, but I have no idea why and it's not an easy task to debug
streams. I'll keep trying, though - but I'm sure the developers would
definitely have a better idea of what's going on. I'll post it as a bug, I
guess - it definitely looks like one.



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Re: Strange error while doing redirects in Jetty 5.1.3

Chris Haynes
Yes, but whose bug do you think it is?

There's so much going on here, and so many different technologies involved, I
would really try to narrow down the area of the problem before posting it as a
bug, if I were you.

Any chance of putting a packet sniffer on the network, to look at the contents
of the headers and requests as they go to and fro?  That might narrow down the
time / location of the problem.

Chris

----- Original Message -----
From: "Alex Savitsky" <[hidden email]>
To: <[hidden email]>
Sent: Friday, May 20, 2005 8:42 PM
Subject: [Jetty-support] Re: Strange error while doing redirects in Jetty 5.1.3


> Chris Haynes <chris <at> harvington.org.uk> writes:

>
> Well, it appears as if at some stage something has presented a load of non-
ASCII
> characters to a browser, and it has used %HH encoding on it.  What's curious
is
> that it seems to have encoded some non-ASCII values 'properly' using the %HH
> notation, but has let through others which are plainly not (7-bit) ASCII.
>
> Presumably you know what the 'correct' file names in
>     C:/Personal/Java/workspace/SimpleApp/context/
> are.
>
> I hope there are only 7-bit ASCII characters in these  names.  Redirect uses
an
> HTTP header for which there is no 'official' support for non-ASCII
characters.
> If you are giving it a URL with non-ASCII characters there will _always_ be
> uncertainty as to what will happen.
>
> If you _have_ to have non-ASCII characters in the URL I would recommend one
of
> two approaches:
>
> 1) encode them yourself using a 'private' encoding which you remove when the
> request comes back,
>
> 2) put the file name into the query part opf the URL (after a ?) and use
> URL-encoding on it before you send it - you convert all non-ASCII characters
> into %HH triplets, so that the URL you ask it to forward to would look
something
> like
>
> http://site/servlet?f=B%C2%8E%15
>
> Then, rather messily, you would have to cope with turning this into a
resource
> look-up on reception.
>
> Non-ASCII characters in URLs are to be avoided at all costs!
>
> Chris Haynes
>
> "Alex Savitsky" asked:
>
> I was trying some black magic with Spring/Tapestry, and at one moment, I
needed

> to execute a redirect twice (using the HttpServletResponse.sendRedirect()).
> After the second redirect, here's what I've got in stack trace:
>
> java.io.IOException: The filename, directory name, or volume label syntax is
> incorrect
> at java.io.WinNTFileSystem.canonicalize0(Native Method)
> at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:395)
> at java.io.File.getCanonicalPath(File.java:531)
> at org.mortbay.util.FileResource.getAlias(FileResource.java:162)
> at org.mortbay.http.ResourceCache.getResource(ResourceCache.java:252)
> at org.mortbay.http.HttpContext.getResource(HttpContext.java:2135)
> at org.mortbay.jetty.servlet.WebApplicationContext.getResource
> (WebApplicationContext.java:775)
> at org.mortbay.jetty.servlet.Default.getResource(Default.java:185)
> at org.mortbay.jetty.servlet.Default.service(Default.java:209)
> << pruned >>
> WARN - Alias request of 'file:/C:/Personal/Java/workspace/SimpleApp/context/B%
> C2%8E%15Áçi%C2%99%C2%9A%13â¦%C2%92óÝX²%12%1A%0BA¥s׸%C2%9F%C2%9B%01t%C2%8BÏ5%
03
>
> I'm not sure whether mail would be able to reproduce the exact sequence of
> garbage in the last line (the one with "WARN - Alias request of" in the
> beginning), but I'll put it here anyway.
>
> Strangely enough, the application itself behaved as if nothing happened - no
> exceptions thrown, it simply didn't load the page. sendRedirect() didn't
report
> anything, either.
>
> What's even more strange - when I use Mozilla FireFox, I cannot get this
> problem - only if I'm using IE6 (v.6.0.2800.1106 if it matters). Now, I know,
I
> know - "Micro$oft suxx" - but my user base wouldn't take that as an
> explanation, unfortunately :(
>
> So, had anybody seen anything like that? Any ideas?
>
> Thanks in advance,
>
> Alex
>

The thing is - if something had introduced these garbage characters into the
URL, it's anything but my app. All my files are 7-bit ASCII, I haven't been
playing with the localizations yet, and I checked my project folder again just
to be sure Eclipse haven't introduced any funny stuff in there (it haven't).
BTW, the characters appeared unencoded in my exception trace, they got encoded
to %NN form when I posted them to mail list.

I tried to trace the problem, got all the way down to
org.mortbay.http.HttpRequest.readHeader() - it doesn't look like something
introduced into URL, after all. Apparently it gets all this garbage in the
LineInput buffer, but I have no idea why and it's not an easy task to debug
streams. I'll keep trying, though - but I'm sure the developers would
definitely have a better idea of what's going on. I'll post it as a bug, I
guess - it definitely looks like one.



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support





-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Strange error while doing redirects in Jetty 5.1.3

Alex Savitsky
Chris Haynes <chris <at> harvington.org.uk> writes:

>
> Yes, but whose bug do you think it is?
>
> There's so much going on here, and so many different technologies involved, I
> would really try to narrow down the area of the problem before posting it as
a
> bug, if I were you.
>
> Any chance of putting a packet sniffer on the network, to look at the
contents
> of the headers and requests as they go to and fro?  That might narrow down
the
> time / location of the problem.
>
> Chris

Not as many technologies as you think. I was able to narrow the problem down to
only Jetty & JettyLauncher. Here's how to reproduce it:

test.jsp:
<% response.sendRedirect("https://localhost:8443/test2.jsp"); %>

test2.jsp:
<% response.sendRedirect("/test3.jsp"); %>

test3.jsp:
Can be whatever you like.

jetty.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure 1.1//EN"
        "http://jetty.mortbay.org/configure_1_2.dtd">
<Configure class="org.mortbay.jetty.plus.Server">
        <Call name="addListener">
                <Arg>
                        <New class="org.mortbay.http.SocketListener">
                                <Set name="Host">localhost</Set>
                                <Set name="Port">
                                        <SystemProperty name="jetty.port"
default="8080"/>
                                </Set>
                                <Set name="MinThreads">10</Set>
                                <Set name="MaxThreads">100</Set>
                                <Set name="MaxIdleTimeMs">30000</Set>
                        </New>
                </Arg>
        </Call>
        <Call name="addListener">
                <Arg>
                        <New class="org.mortbay.http.SslListener">
                                <Set name="Host">localhost</Set>
                                <Set name="Port">8443</Set>
                                <Set name="PoolName">P1</Set>
                                <Set name="MaxIdleTimeMs">30000</Set>
                                <Set name="lowResources">30</Set>
                                <Set name="LowResourcePersistTimeMs">2000</Set>
                                <Set name="Keystore"><SystemProperty
name="jetty.home"
                                        default="."/>/etc/demokeystore</Set>
                                <Set
name="Password">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
                                <Set
name="KeyPassword">OBF:1u2u1wml1z7s1z7a1wnl1u2g</Set>
                                <Set name="HttpHandler">
                                        <New
class="org.mortbay.http.handler.MsieSslHandler">
                                                <Set
name="UserAgentSubString">MSIE 5</Set>
                                        </New>
                                </Set>
                        </New>
                </Arg>
        </Call>
        <Call name="addWebApplication">
                <Arg/>
                <Arg>/</Arg>
                <Arg>context</Arg>
        </Call>
</Configure>

Place all three JSPs in the app root, run Jetty using launcher and the attached
XML file, and execute test.jsp. Presto!

Unfortunately, the network sniffers are not allowed on our network, so I won't
be able to do that. In any case, I believe the problem is now sufficiently
narrowed down to be posted as a bug.

Alex



-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Re: Strange error while doing redirects in Jetty 5.1.3

Chris Haynes
Ahah!!!

You didn't say before that HTTPS was involved.

Got it! I've seen this one before and, yes - as you originally declared -
"Micro$oft suxx".

The problem is prebably that MSIE is interpreting your redirects as involving
different ports, but is failing to switch into / out of HTTPS as it swaps port.

The garbage you are seeing is one end of the connection trying to negotiate an
HTTPS session when the other end thinks that an unencrypted communication is in
order.

I can't tell, from what you have posted,  if the problem in your particular
situation is that MSIE is attempting to read an HTTPS port as if it speaks HTTP,
or the other way around.

M$ bug, I'm afraid, a subtle one and one that's been discussed here before.
IIRC I also found it recorded on a more general M$ bugs web site.

My recommended work-around: don't change between HTTP and HTTPS while doing
redirects (or give M$ the impression that that's what you intend).

Perhaps making the second redirect more explicit
:"https://localhost:8443/test3.jsp" will work.

The good news is that this is a fix which you should be able to implement
without inconveniencing your users, or having to use M$ 'poor quality' as an
excuse.

HTH

Oh, and BTW, you did a great job in refining the test case, but you still had
JSP involved, and that counts as a distinct (often-buggy) technology around here
;-)

Chris Haynes


"Alex Savitsky" responded:


> Chris Haynes <chris <at> harvington.org.uk> writes:
>
>>
>> Yes, but whose bug do you think it is?
>>
>> There's so much going on here, and so many different technologies involved, I
>> would really try to narrow down the area of the problem before posting it as
> a
>> bug, if I were you.
>>
>> Any chance of putting a packet sniffer on the network, to look at the
> contents
>> of the headers and requests as they go to and fro?  That might narrow down
> the
>> time / location of the problem.
>>
>> Chris
>
> Not as many technologies as you think. I was able to narrow the problem down
> to
> only Jetty & JettyLauncher. Here's how to reproduce it:
>
> test.jsp:
> <% response.sendRedirect("https://localhost:8443/test2.jsp"); %>
>
> test2.jsp:
> <% response.sendRedirect("/test3.jsp"); %>
>
> test3.jsp:
> Can be whatever you like.
>
> jetty.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure 1.1//EN"
> "http://jetty.mortbay.org/configure_1_2.dtd">
> <Configure class="org.mortbay.jetty.plus.Server">
> <Call name="addListener">
> <Arg>
> <New class="org.mortbay.http.SocketListener">
> <Set name="Host">localhost</Set>
> <Set name="Port">
> <SystemProperty name="jetty.port"
> default="8080"/>
> </Set>
> <Set name="MinThreads">10</Set>
> <Set name="MaxThreads">100</Set>
> <Set name="MaxIdleTimeMs">30000</Set>
> </New>
> </Arg>
> </Call>
> <Call name="addListener">
> <Arg>
> <New class="org.mortbay.http.SslListener">
> <Set name="Host">localhost</Set>
> <Set name="Port">8443</Set>
> <Set name="PoolName">P1</Set>
> <Set name="MaxIdleTimeMs">30000</Set>
> <Set name="lowResources">30</Set>
> <Set name="LowResourcePersistTimeMs">2000</Set>
> <Set name="Keystore"><SystemProperty
> name="jetty.home"
> default="."/>/etc/demokeystore</Set>
> <Set
> name="Password">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
> <Set
> name="KeyPassword">OBF:1u2u1wml1z7s1z7a1wnl1u2g</Set>
> <Set name="HttpHandler">
> <New
> class="org.mortbay.http.handler.MsieSslHandler">
> <Set
> name="UserAgentSubString">MSIE 5</Set>
> </New>
> </Set>
> </New>
> </Arg>
> </Call>
> <Call name="addWebApplication">
> <Arg/>
> <Arg>/</Arg>
> <Arg>context</Arg>
> </Call>
> </Configure>
>
> Place all three JSPs in the app root, run Jetty using launcher and the
> attached
> XML file, and execute test.jsp. Presto!
>
> Unfortunately, the network sniffers are not allowed on our network, so I won't
> be able to do that. In any case, I believe the problem is now sufficiently
> narrowed down to be posted as a bug.
>
> Alex
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
> online with coworkers and clients while avoiding the high cost of travel and
> communications. There is no equipment to buy and you can meet as often as
> you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>
>




-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Strange error while doing redirects in Jetty 5.1.3

Alex Savitsky
>
> Ahah!!!
>
> You didn't say before that HTTPS was involved.
>
> Got it! I've seen this one before and, yes - as you originally declared -
> "Micro$oft suxx".
>
> The problem is prebably that MSIE is interpreting your redirects as involving
> different ports, but is failing to switch into / out of HTTPS as it swaps
port.
>
> The garbage you are seeing is one end of the connection trying to negotiate
an
> HTTPS session when the other end thinks that an unencrypted communication is
in
> order.
>
> I can't tell, from what you have posted,  if the problem in your particular
> situation is that MSIE is attempting to read an HTTPS port as if it speaks
HTTP,

> or the other way around.
>
> M$ bug, I'm afraid, a subtle one and one that's been discussed here before.
> IIRC I also found it recorded on a more general M$ bugs web site.
>
> My recommended work-around: don't change between HTTP and HTTPS while doing
> redirects (or give M$ the impression that that's what you intend).
>
> Perhaps making the second redirect more explicit
> :"https://localhost:8443/test3.jsp" will work.
>
> The good news is that this is a fix which you should be able to implement
> without inconveniencing your users, or having to use M$ 'poor quality' as an
> excuse.
>
> HTH
>
> Oh, and BTW, you did a great job in refining the test case, but you still had
> JSP involved, and that counts as a distinct (often-buggy) technology around
here
>
>
> > Not as many technologies as you think. I was able to narrow the problem
down

> > to
> > only Jetty & JettyLauncher. Here's how to reproduce it:
> >
> > test.jsp:
> > <% response.sendRedirect("https://localhost:8443/test2.jsp"); %>
> >
> > test2.jsp:
> > <% response.sendRedirect("/test3.jsp"); %>
> >
> > test3.jsp:
> > Can be whatever you like.
> >
> > Place all three JSPs in the app root, run Jetty using launcher and the
> > attached
> > XML file, and execute test.jsp. Presto!
> >
> > Unfortunately, the network sniffers are not allowed on our network, so I
won't
> > be able to do that. In any case, I believe the problem is now sufficiently
> > narrowed down to be posted as a bug.
> >
> > Alex

Chris,

Indeed, it looks like it's the second (implicit) redirect that confuses the IE.
Using only explicit URLs takes care of the problem. Oh well, the unbeatable M$
quality...

Couldn't help not having a protocol switch altoghether, though - HTTPS is a
requirement :(

Regarding JSPs - point taken ;) Though as much as I dislike it myself - it
definitely beats down servlets in terms of overall test case complexity.

I guess I'll go start figuring out how to remove that bug I posted on Friday...

Thanks for your help,

Alex



-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support