
|
If you were logged in you would be able to see more operations.
|
|
|
|
|
| Component/s: |
Server
|
| Affects Version/s: |
0.9.0
|
| Fix Version/s: |
0.9.2
|
|
|
Environment:
|
Debian Etch
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03)
Mozilla Firefox 1.5.0.7
Debian Etch
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03)
Mozilla Firefox 1.5.0.7
|
|
|
It seems that the Selenium proxy forwards the GET operations from the browser as POST operations when the browser downloads a Java applet jar file if -proxyInjectionMode is used.
|
|
Description
|
It seems that the Selenium proxy forwards the GET operations from the browser as POST operations when the browser downloads a Java applet jar file if -proxyInjectionMode is used.
|
Show » |
|
The problem is that ProxyHandler.java assumes that if the browser's HTTP request includes a Content-Type header, then the browser's request must therefore contain content. In that case, ProxyHandler forcibly changes the method to POST.
(For some unknowable reason, the browser JRE plugin passes a Content-Type on its jar GET requests; this is semantically incorrect, unless the browser is trying to send a JAR to the server in the body of a GET request!)
Anyway, I've checked in a fix in RC revision 1939 to address this case. Now we assume that a GET request has no body, even if the GET request includes a Content-Type header.
In investigating this problem I found and fixed
. (Don't forget to clear your Java cache using the Java Control Panel before attempting to test this fix.)
SRC-326, which is a much more serious problem that would totally break applets. I suspect thatSRC-132may have been misdiagnosed as the cause of more general problems with applets, since doing an empty POST seemed not to harm anything; anyway, applets seem to work better now in PI mode. My test case washttp://java.sun.com/docs/books/tutorial/uiswing/components/applet.html