FF3: why simple proxy redirect URL doesn't work?
Jeff Papineau
Is there a new security feature in FF3 that changes the rules on how
proxy URLs redirect?
This JS below works fine in FF2.
We are using a different port and machine to host IE, and FF hits the
regular server and gets proxy'd to the same port thru the server that
sent the page.
But in FF3 it just stops working; we have no idea why.
Compared the Ajax packet that gets sent out by the browser, and the
server hangs on the response, since firebug reports the response as
"undefined".
Like this:
function init() {
if (browser.isIE) {
ajaxServer = server + ':8080/'; // FF does not allow, IE only
} else {
ajaxServer = server + '/xml/'; // <<- FF2 is fine, FF3 very
unhappy
}
}
and later:
ajaxRequest.open('POST', ajaxServer + '?' + sessionId, true);
FF2 works fine:
Request-
<P T="200"><F N="1">1</F><F N="2">5</F><F N="3">1</F><F N="4">1</F><F
N="5">surfbo</F><F N="7">AJAX<
/F><F N="8">Netscape</F><F N="9">1</F></P>
response-
<A><P T="201"><F N="1">LbME1I154</F><F N="2">161205fa-be8a-4f18-
a664-2a8e9ce0601d</F></P></A>
FF3 does not:
Request-
<P T="200"><F N="1">1</F><F N="2">5</F><F N="3">1</F><F N="4">1</F><F
N="5">surfbo</F><F N="7">AJAX<
/F><F N="8">Netscape</F><F N="9">1</F></P>
response-
-?????< ???6Connection to server has been lost. Please login again
You can see the server is sending back very different responses, to
what appear to be identical requests.
Not sure what to think about this, but we have duplicated this problem
on several different machines; it's not just me.
Any clues or ideas, please post.
thanks,
Jeff
EE
this page to see if it helps:
http://kb.mozillazine.org/Network.security.ports.banned.override
Roland de Ruiter
Do you know if anything gets sent out of FF3 and to the proxy (or
server)? Does it actually send out a HTTP request?
To monitor this you could use
- the FF extension *Live HTTP Headers*
<https://addons.mozilla.org/en-US/firefox/addon/3829>
- a TCP monitor, e.g. Sysinternals' *TCPView*
<http://technet.microsoft.com/nl-nl/sysinternals/bb897437(en-us).aspx>),
- or a network sniffer
Where does the trace of the request come from (I mean the <P T="200"><F
N="1">...</F></P>). From the server, from the proxy, from the client
(i.e. Firefox)?
The request traces from FF2 and FF3 appear to be the same. If these
originate from the server (or proxy), then something gets sent out of FF3.
Maybe a stupid question, but do you actually do a
ajaxRequest.send(null); // null or whatever data needs to be sent
after the ajaxRequest.open call?
Does the proxy allow FF3 to access a webpage (i.e. maybe the proxy
allows only certain clients and is it perhaps blocking FF3)?
The page <http://developer.mozilla.org/en/docs/XMLHttpRequest> shows
some changes for FF3, e.g. some change regarding the request encoding.
FF3 doesn't necessarily use UTF-8. For instance, your server application
may be waiting on a second UTF-8 byte from FF3, while FF3 sent the data
in a single byte-encoding only(eg ISO-8859-1).
--
Regards,
Roland
Jeff Papineau
<roland.de.rui...@example.invalid> wrote:
> Do you know if anything gets sent out of FF3 and to the proxy (or
> server)? Does it actually send out a HTTP request?
Yes, I use Fiddler and FBug to see the network traffic going out of
the client. That's where I get the comparison data to see what is
getting sent out.
> Does the proxy allow FF3 to access a webpage (i.e. maybe the proxy
> allows only certain clients and is it perhaps blocking FF3)?
Yes, of course, something like this makes sense. thx.
> The page <http://developer.mozilla.org/en/docs/XMLHttpRequest> shows
> some changes for FF3, e.g. some change regarding the request encoding.
> FF3 doesn't necessarily use UTF-8. For instance, your server application
> may be waiting on a second UTF-8 byte from FF3, while FF3 sent the data
> in a single byte-encoding only(eg ISO-8859-1).
Again, great reference.
Thanks Roland, wonderful advice.
I'm guessing one of these puts us on the path to a solution.
Jeff-