Re: Request.getRequestURL and Response.sendRedirect
stefan <[email protected]> Wed, 19 Jul 2006 20:45:58 +0200
| Newsgroups | gmane.text.xml.resin.user |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_129759_21338461.1153334758128 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Indeedy - I should have checked the bug tracker I thought 3.0 had the same problem, but I didn't test it, only 2.1 Probably the fix wasn't backported, which is understandable... I guess I'll just use a request wrapper. Thanks ! On 7/19/06, Knut Forkalsrud <[email protected]> wrote: > > I reported a bug on getServerPort() a while back > http://bugs.caucho.com/view.php?id=77 which was resolved so that it > now uses the HTTP/1.1 Host header, so I'm surprised that you see > different behavior. Or maybe I don't understand your test case... > > -Knut > > > > stefan <[email protected]> writes: > > > Hi everyone, > > > > Here's my issue in short: we're integrating a 3rd party jar that > > uses Request.getRequestURL to build (surprise!) a URL; we run resin > > on port 8080, and the resulting URL contains ":8080", which we don't > > like. > > > > After some quick tests and source-peeking, it looks like > > Response.sendRedirect does the 'proper' thing: if an HTTP 'Host' > > header is present, its value is used instead of > > getServerName()/getServerPort() (see > > AbstractHttpResponse.getAbsolutePath ) > > > > My question is: shouldn't Request.getRequestURL (and maybe > > HttpUtils.getRequestURL while we're at it) use the same logic to > > compute the URL ? The HTTP spec (see > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23 ) > > seems to agree :p > > > > This code seems to be the same on resin 2.1.17 and 3.0.19 > > > > Stefan > > ------=_Part_129759_21338461.1153334758128 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,<br><br>Indeedy - I should have checked the bug tracker <br><br>I thought 3.0 had the same problem, but I didn't test it, only 2.1<br>Probably the fix wasn't backported, which is understandable...<br><br>I guess I'll just use a request wrapper. <br><br>Thanks !<br><br><br><div><span class="gmail_quote">On 7/19/06, <b class="gmail_sendername">Knut Forkalsrud</b> <<a href="mailto:[email protected]">[email protected]</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I reported a bug on getServerPort() a while back<br><a href="http://bugs.caucho.com/view.php?id=77">http://bugs.caucho.com/view.php?id=77</a> which was resolved so that it<br>now uses the HTTP/1.1 Host header, so I'm surprised that you see <br>different behavior. Or maybe I don't understand your test case...<br><br>-Knut<br><br><br><br>stefan <<a href="mailto:[email protected]">[email protected]</a>> writes:<br><br>> Hi everyone,<br>><br>> Here's my issue in short: we're integrating a 3rd party jar that <br>> uses Request.getRequestURL to build (surprise!) a URL; we run resin<br>> on port 8080, and the resulting URL contains ":8080", which we don't<br>> like.<br>><br>> After some quick tests and source-peeking, it looks like <br>> Response.sendRedirect does the 'proper' thing: if an HTTP 'Host'<br>> header is present, its value is used instead of<br>> getServerName()/getServerPort() (see<br>> AbstractHttpResponse.getAbsolutePath ) <br>><br>> My question is: shouldn't Request.getRequestURL (and maybe<br>> HttpUtils.getRequestURL while we're at it) use the same logic to<br>> compute the URL ? The HTTP spec (see<br>> <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23"> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23</a> )<br>> seems to agree :p<br>><br>> This code seems to be the same on resin 2.1.17 and 3.0.19<br>><br>> Stefan<br><br></blockquote></div><br> ------=_Part_129759_21338461.1153334758128--