uri_for adding :443 to URL when HTTPS=on

[Charlie Garrison]

Good evening,

I upgraded Catalyst-Runtime from 5.7007 to 5.7010 yesterday; and
that seems to be the cause of this problem. But it could have
been there before and it was never reported by our users.

When users try to login <https://www.resultsplus.com.au/progs/>,
the following error is returned:

     Bad Request
     Your browser sent a request that this server could not understand.
     Client sent malformed Host header
     Apache/1.3.29 Server at www.resultsplus.com.au:443:8627
Port 443

Catalyst is doing a redirect to the login page using:

     $c->response->redirect($c->uri_for('/login'));

As far as I can tell, that is when :443 is being added to the URL.

The above error makes sense in the context of frontend/backend
apache with rewrite rules.

     RewriteRule ^/login(.*)$    
http://%{HTTP_HOST}:8627/progs/login$1 [P]
     RewriteRule ^/progs/(.*)$  
http://%{HTTP_HOST}:8627/progs/$1 [P]

I'm redirecting to and using different ports on the backend to
identify secure connections, and then setting ENV as:

     PerlSetEnv HTTPS "on"

So, assuming I'm reaching the correct conclusion (that uri_for
is the culprit), how do I prevent it from adding :443 to the URL?

I've fixed it temporarily using a rewrite rule with hard-coded
value in place of %{HTTP_HOST}, but the :443 port is being added
to every URL created with uri_for throughout the site.

I've had a look at Catalyst::uri_for sub and it seems to be
getting the 'base' from the URI object. But I'm running short of
debug fu and would appreciate some assistance at this point.

Thanks,
Charlie

--
    Charlie Garrison  <garrison@...>
    PO Box 141, Windsor, NSW 2756, Australia

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
http://www.ietf.org/rfc/rfc1855.txt

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Matt S Trout-2]

On Tue, Aug 28, 2007 at 08:34:16PM +1000, Charlie Garrison wrote:

> Good evening,
>
> I upgraded Catalyst-Runtime from 5.7007 to 5.7010 yesterday; and
> that seems to be the cause of this problem. But it could have
> been there before and it was never reported by our users.
>
> When users try to login <https://www.resultsplus.com.au/progs/>,
> the following error is returned:
>
>     Bad Request
>     Your browser sent a request that this server could not understand.
>     Client sent malformed Host header
>     Apache/1.3.29 Server at www.resultsplus.com.au:443:8627
> Port 443
>
> Catalyst is doing a redirect to the login page using:
>
>     $c->response->redirect($c->uri_for('/login'));
>
> As far as I can tell, that is when :443 is being added to the URL.
>
> The above error makes sense in the context of frontend/backend
> apache with rewrite rules.
>
>     RewriteRule ^/login(.*)$    
> http://%{HTTP_HOST}:8627/progs/login$1 [P]
>     RewriteRule ^/progs/(.*)$  
> http://%{HTTP_HOST}:8627/progs/$1 [P]

That's kinda broken, it's relying on the request header which a browser
could easily cock up.

I suspect %{REMOTE_HOST} would be better (see the mod_rewrite docs for
more info)

--
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director    Want a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/                    http://www.shadowcat.co.uk/ 

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Charlie Garrison]

Good evening,

On 3/9/07 at 7:54 PM +0100, Matt S Trout
<dbix-class@...> wrote:

>>  The above error makes sense in the context of
>>frontend/backend  apache with rewrite rules.
>>       RewriteRule ^/login(.*)$    
>>http://%{HTTP_HOST}:8627/progs/login$1 [P]
>>      RewriteRule ^/progs/(.*)$    
>>http://%{HTTP_HOST}:8627/progs/$1 [P]
>
>That's kinda broken, it's relying on the request header which a browser
>could easily cock up.

Fair enough, although I've seen heaps of examples using
%{HTTP_HOST} so I followed along.

>I suspect %{REMOTE_HOST} would be better (see the mod_rewrite docs for
>more info)

REMOTE_HOST seems to be the client host name, not the server. So
I don't think that's the one you meant. Did you mean SERVER_NAME
instead? Since SERVER_NAME seems to give the value I expect,
I'll switch to using that. Still doesn't really solve the core
issue though.

When I generate a URI string with $c->uri_for(...) and HTTPS=on,
then I get :443 as part of the URI string. What can I do in my
Catalyst config (or elsewhere) to prevent :443 being included in
the URI string?

Thanks,
Charlie

--
    Charlie Garrison  <garrison@...>
    PO Box 141, Windsor, NSW 2756, Australia

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
http://www.ietf.org/rfc/rfc1855.txt

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Matt S Trout-2]

On Tue, Sep 04, 2007 at 11:24:43PM +1000, Charlie Garrison wrote:

> Good evening,
>
> On 3/9/07 at 7:54 PM +0100, Matt S Trout
> <dbix-class@...> wrote:
>
> >> The above error makes sense in the context of
> >>frontend/backend  apache with rewrite rules.
> >>      RewriteRule ^/login(.*)$    
> >>http://%{HTTP_HOST}:8627/progs/login$1 [P]
> >>     RewriteRule ^/progs/(.*)$    
> >>http://%{HTTP_HOST}:8627/progs/$1 [P]
> >
> >That's kinda broken, it's relying on the request header which a browser
> >could easily cock up.
>
> Fair enough, although I've seen heaps of examples using
> %{HTTP_HOST} so I followed along.
>
> >I suspect %{REMOTE_HOST} would be better (see the mod_rewrite docs for
> >more info)
>
> REMOTE_HOST seems to be the client host name, not the server. So
> I don't think that's the one you meant. Did you mean SERVER_NAME
> instead? Since SERVER_NAME seems to give the value I expect,
> I'll switch to using that.

Damn. Yes, sorry.

Rewrite setup configs always fall out of my head if I don't do one for a
few days.

> Still doesn't really solve the core
> issue though.

I thought the core issue was that your rewrite rules were broken?

> When I generate a URI string with $c->uri_for(...) and HTTPS=on,
> then I get :443 as part of the URI string. What can I do in my
> Catalyst config (or elsewhere) to prevent :443 being included in
> the URI string?

Have you checked to see what your webserver's giving Catalyst? I'm not
sure this isn't just uri_for naively working with what the webserver gives
it.

--
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director    Want a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/                    http://www.shadowcat.co.uk/ 

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Charlie Garrison]

Good morning,

On 4/9/07 at 4:44 PM +0100, Matt S Trout
<dbix-class@...> wrote:

>>  REMOTE_HOST seems to be the client host name, not the
>>server. So  I don't think that's the one you meant. Did you
>>mean SERVER_NAME  instead? Since SERVER_NAME seems to give the
>>value I expect,  I'll switch to using that.
>
>Damn. Yes, sorry.
>
>Rewrite setup configs always fall out of my head if I don't do one for a
>few days.

Or even a few hours for some of us.  ;-)

>>  Still doesn't really solve the core  issue though.
>
>I thought the core issue was that your rewrite rules were broken?

Sorry for not being clear. I was giving that info as background
and to show how I was working around the issue.

>>  When I generate a URI string with $c->uri_for(...) and
>>HTTPS=on,  then I get :443 as part of the URI string. What can
>>I do in my  Catalyst config (or elsewhere) to prevent :443
>>being included in  the URI string?
>
>Have you checked to see what your webserver's giving Catalyst? I'm not
>sure this isn't just uri_for naively working with what the webserver gives
>it.

To confirm, I'm using a rewrite rule such as:

     # uses custom port on backend to indicate https - sets HTTPS=on
     # Catalyst app base is /progs
     RewriteRule ^/progs/(.*)$  
http://%{SERVER_NAME}:8627/progs/$1 [P]

I'm printing this to error_log (request for https://www.resultsplus.com.au/progs/):

INFO - ***Root::auto HTTPS: on
INFO - ***Root::auto HTTP_HOST: www.resultsplus.com.au:8627
INFO - ***Root::auto c->req->path:
INFO - ***Root::auto c->req->secure: 1
INFO - ***Root::auto c->req->base: https://www.resultsplus.com.au:443/progs/
INFO - ***Root::auto c->req->uri: https://www.resultsplus.com.au:443/progs/
INFO - ***Root::auto c->req->uri->scheme: https
INFO - ***Root::auto c->req->uri->opaque: //www.resultsplus.com.au:443/progs/
INFO - ***Root::auto c->req->uri->port: 443
INFO - ***Root::auto c->req->uri->host_port: www.resultsplus.com.au:443
INFO - ***Root::auto c->uri_for: https://www.resultsplus.com.au:443/progs/

I believe this is an issue with the URI module adding port 443
since the port in the request is not the 'standard' https port.
Assuming that is accurate, what is the correct way in Catalyst
to 'correct' the URI value? Is it a bug or something I need to
be doing differently?

Thanks,
Charlie

--
    Charlie Garrison  <garrison@...>
    PO Box 141, Windsor, NSW 2756, Australia

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
http://www.ietf.org/rfc/rfc1855.txt

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Andy Grundman]

On Aug 28, 2007, at 6:34 AM, Charlie Garrison wrote:

> Good evening,
>
> I upgraded Catalyst-Runtime from 5.7007 to 5.7010 yesterday; and  
> that seems to be the cause of this problem. But it could have been  
> there before and it was never reported by our users.
>
> When users try to login <https://www.resultsplus.com.au/progs/>,  
> the following error is returned:
>
>     Bad Request
>     Your browser sent a request that this server could not understand.
>     Client sent malformed Host header
>     Apache/1.3.29 Server at www.resultsplus.com.au:443:8627 Port 443
>
> Catalyst is doing a redirect to the login page using:
>
>     $c->response->redirect($c->uri_for('/login'));
>
> As far as I can tell, that is when :443 is being added to the URL.
>
> The above error makes sense in the context of frontend/backend  
> apache with rewrite rules.
>
>     RewriteRule ^/login(.*)$    http://%{HTTP_HOST}:8627/progs/login
> $1 [P]
>     RewriteRule ^/progs/(.*)$   http://%{HTTP_HOST}:8627/progs/$1 [P]
>
> I'm redirecting to and using different ports on the backend to  
> identify secure connections, and then setting ENV as:
>
>     PerlSetEnv HTTPS "on"
>
> So, assuming I'm reaching the correct conclusion (that uri_for is  
> the culprit), how do I prevent it from adding :443 to the URL?
>
> I've fixed it temporarily using a rewrite rule with hard-coded  
> value in place of %{HTTP_HOST}, but the :443 port is being added to  
> every URL created with uri_for throughout the site.
>
> I've had a look at Catalyst::uri_for sub and it seems to be getting  
> the 'base' from the URI object. But I'm running short of debug fu  
> and would appreciate some assistance at this point.

I've just checked in a fix for this bug, port 443 should no longer be  
added to base/uri.

http://dev.catalystframework.org/svnweb/Catalyst/revision/?rev=6895

-Andy

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Charlie Garrison]

Good evening,

On 14/9/07 at 12:32 PM -0400, Andy Grundman
<andy@...> wrote:

>I've just checked in a fix for this bug, port 443 should no longer be added to base/uri.
>
>http://dev.catalystframework.org/svnweb/Catalyst/revision/?rev=6895

I've applied patches from rev 6895 & 6896. The issue with port
443 being added to URLs is resolved here. Thanks for the fix.


Charlie

--
    Charlie Garrison  <garrison@...>
    PO Box 141, Windsor, NSW 2756, Australia

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
http://www.ietf.org/rfc/rfc1855.txt

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/