Response.Redire ct from SSL to non SSL with port drops port.

[Sean Wolfe]

I have this wierd bizarrre problem that I'm experienceing with the
Response.Redire ct() method.

I have a site where the users are on a particular page in SSL. When they
post the data back, and the processing is done, it then tries to
redirect them back to the non-SSL site. But the site is on a
non-starndard port number. I place in the Response.Redire ct() method the
Fully qualified path to the URL and when ASP.NET makes the Response, the
response drops the port number, therefore redirecting the user to a 404.

For example:
Users are on a page:
https://www.somefqd.com/selectCustom...hblah=blahblah

they post back some data, and then the aspx page process the data, and
then a call to Response.Redire ct()

Response.Redire ct("http://www.somefqd.com :8080/default.aspx");

What I end up seeing, using fiddler, the request ends up being
http://www.somefd.com/default.aspx.

It's quite strange, becuase I even drop into the debug code and make
sure that the string passed to Response.Redire ct is the fully qualified
path. Any idea's on what is happening here?

Sean

[Joerg Jooss]

Sean Wolfe wrote:

I have this wierd bizarrre problem that I'm experienceing with the
Response.Redire ct() method.

I have a site where the users are on a particular page in SSL. When
they post the data back, and the processing is done, it then tries to
redirect them back to the non-SSL site. But the site is on a
non-starndard port number. I place in the Response.Redire ct() method
the Fully qualified path to the URL and when ASP.NET makes the
Response, the response drops the port number, therefore redirecting
the user to a 404.

For example:
Users are on a page:
https://www.somefqd.com/selectCustom...hblah=blahblah

they post back some data, and then the aspx page process the data,
and then a call to Response.Redire ct()

Response.Redire ct("http://www.somefqd.com :8080/default.aspx");

What I end up seeing, using fiddler, the request ends up being
http://www.somefd.com/default.aspx.

It's quite strange, becuase I even drop into the debug code and make
sure that the string passed to Response.Redire ct is the fully
qualified path. Any idea's on what is happening here?

Actually, this problem is not that bizarre. I've been there twice
already ;-)

This will happen for example
- if the HTTP Location header produced by the redirecting code is
accidentally relative or
- a firewall or proxy incorrectly translates port numbers from an
internal network to the Internet or vice versa.

I suggest to ask your networking guys to help you with this.

Cheers,
--
http://www.joergjooss.de
mailto:ne****** **@joergjooss.d e