Re: Problem with Response.Redirect and Proxy Server
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 12/10/04
- Next message: David Wang [Msft]: "Re: IIS won't serve PDF"
- Previous message: David Wang [Msft]: "Re: HOWTO Send an email to a Web Server."
- In reply to: Neil Kiser: "Re: Problem with Response.Redirect and Proxy Server"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 10 Dec 2004 07:01:49 -0800
> This make sound silly, but we have nod been seeing this
> and we had assumed that the 302 was handled quietly and
> that the URL did not change until the resource was acquired.
Ah, a bank. Think think about it this way - a browser is literally
obligated to show the new URL of a 302. If a web server just told the
browser "go there instead", it would be totally negligent for the browser to
hide this fact from the user. This is the sort of problem that cross-site
scripting vulnerability thrives on.
It is a good piece of info to know that there is a reverse proxy. You need
to figure out whether this reverse proxy remaps both IP and Ports. In other
words, outside clients request a.b.c.d:80 and the reverse proxy
translates it to e.f.g.h:8080 in the internal network.
Clearly, the ASP page needs to tell the client to make a 302 redirection to
a.b.c.d:80 , but while the ASP page is running, it may not know a.b.c.d
nor 80 (it knows it is running on a website at e.f.g.h on port 8080, but it
knows nothing about the reverse proxy).
-- //David IIS http://blogs.msdn.com/David.Wang This posting is provided "AS IS" with no warranties, and confers no rights. // "Neil Kiser" <neil@NOSPAMkiserville.com> wrote in message news:36E7EBEB-0696-4D80-9E81-5D7E46EB56FE@microsoft.com... I completely concur with you, and unfortunately can not comply. There's no excuse for it, but the explanation is that I work for a major bank and as such, our divisions are segmented. I have no ability to affect the environment in which this testing must be done and there are many clients for many other apps that reach this environment. In short, while you are 100% correct, I couldn't get SSL turned off to save my life. However, you have answered my question indirectly. I will assume then that there are no known issues with reverse proxy servers and response.redirect/302 messages. I am confident that my code is good. The application works fine if I call it directly, it is only when the URL is masked by a reverse proxy that the problem arises. I appreciate that you can not help me without more information, and it is logical to request that SSL be turned off. But, I'll have to proceed without that benefit. We did advanced yesterday in that I realized that if the browser receives a 302 instruction that it updates the address/URL and then makes the request. This make sound silly, but we have nod been seeing this and we had assumed that the 302 was handled quietly and that the URL did not change until the resource was acquired. Now that we know this, we are uncertain that the 302 is actually making it back to the browser. Our current thinking is that perhaps the proxy server is set to optimize communications and to handle the 302 without involving the client browser. Not being proxy server informed, I have no idea if this is true. So we muddle forward. Thank you for your help. -Neil K. "David Wang [Msft]" wrote: > Your redirection is ambiguously defined that it is more likely than not to > result in a 404. Please do the whole thing with just HTTP to prove that > everything is correct before moving to HTTPS. > > If you cannot, then you are on your own to first prove your code is > redirecting the way it is supposed to before claiming there is an issue with > any proxy/IIS -- just because SSL obscures the issue by encrypting traffic > does not shield you from due diligence. > > You can use a Network sniffer like Ethereal or Network Monitor on the > unencrypted HTTP traffic to see the actual 302 that you are sending. Verify > that it matches RFC2616 (HTTP/1.1 spec) for 302 redirection URL format (i.e. > it is supposed to be an absolute URI). In particular, if you leave the > Location header open to interpretation by the browser and it ends in 404, > it's really your problem -- it's just like if you put an ambiguous relative > URL in an HTML file and the browser fetches the wrong resource when you > click on the link. The problem isn't that the server didn't correct the > HTML or the browser went to the wrong location and got a 404 -- it is > because the HTML was not following specifications and gave bad info. > > -- > //David > IIS > This posting is provided "AS IS" with no warranties, and confers no rights. > // > "Neil Kiser" <neil@NOSPAMkiserville.com> wrote in message > news:F35074EB-E3EB-4F46-BAE9-9A3EA60644B0@microsoft.com... > I am using IIS 5.0 and IE 6.0. I have a page that implements a > response.redirect to "abc.asp". But I get a 404 file not found error. The > web server sits behind a proxy and unfortunately SSL is on. > I'm trying to either locate known problems (KB doesn't seem to have any), or > to find out how I can see the contents of the 302 that the browser receives > so that I can see the URL that it is trying to redirect to. For some reason > the proxy server people say they have no logs for me to examine - so I'm > left > to wonder just want URL the browser is attempting to reach. I have found > sniffers, but I am on SSL and I haven;t yet found a way to see the header as > it is received by the browser. Any advice would be greatly appreciated. > > >
- Next message: David Wang [Msft]: "Re: IIS won't serve PDF"
- Previous message: David Wang [Msft]: "Re: HOWTO Send an email to a Web Server."
- In reply to: Neil Kiser: "Re: Problem with Response.Redirect and Proxy Server"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
