it look like selenium.open sends HEAD before GET,
did a simple test and took a sniffer with it:
[Test]
public void SimpleOpen()
{
  selenium.Open("/");
}
sniffer:
HEAD / HTTP/1.1
Host: www.google.com .....
than
GET / HTTP/1.1
Host: www.google.com
- please make this priority higher since some of our request do not accept HEAD, this
make our tests fail.

This is a serious limitation for us from moving to 1.0.3 because we have a feature in
our AUT that changes behavior on the second time an idential CGI URL is requested.
The HEAD is seen as the first request and the subsequent GET is seen as the second
request -- therefore under 1.0.3 we cannot possibly test the initial state behavior
because when we do get the content back it is already in the second state.

Again, 1.0.1 does NOT do this -- this is an undocumented and undesirable change in
behavior in 1.0.3.

Considering there appear to be known issues creeping up with RC1.0.1 and FF3.6 it is
really problematic to be stuck between these two situations.

I believe we are also affected by the same problem. Our application redirects on
sign-on. On 1.0.3, we are seeing selenium duplicating the requests on redirect. Our
application does not handle duplicate requests well (I won't go into the details).


This problem in RC 1.0.3 is preventing us from upgrading to Selenium Grid 1.0.5 (or
later) because Selenium Grid 1.0.5 contains RC 1.0.3.

Are there any plans to address this?

A couple of nice workarounds are posted on
http://groups.google.com/group/selenium-users/browse_thread/thread/a72e4df5a2fc8d7d#

Sending a second string argument of "true" to open calls is one of them.  It solved
my problem very nicely.

As mentioned in comment 5, this is by design. Passing "true" as the second parameter
to open will disable this behaviour. Marking as WontFix, because this is working as
intended.

Can the workaround from comment 5 be used with selenium remote control? I am using selenium-remote-control-1.0.3\selenium-dotnet-client-driver-1.0.1,
where the Open method only accepts a single parameter, the url. 

I am also using the dot net RC client and, as a matter of fact, the 'Open' method takes
the url as its _single_ parameter.  Consequently, the solution mentioned in comment
5 cannot be applied.  

It seems that, if this behaivour is "by design", then  a corresponding method in the
ISelenium interface allowing to  pass the second boolean argument in order to prevent
the HEAD request before the GET is missing.  As this issue has been (in my opinion,
erroneously) marked as closed, I wonder if a new bug report should be opened.

I agree wit the previous comment, this is a bug - just in RC.
When I hit that problem, I worked-around it on the Apache level:
http://techblog.zabuchy.net/2010/how-to-block-http-requests-for-specific-method

Hi there.  Unfortunately, your workaround assumes that one can modify the server config,
which may not be case always (particularly, in our case). 

I have created a new ticket (Issue 1268) so this matter can be reconsidered by the
dev team.

Issue 1268 has been merged into this issue.

If this is intended behaviour have you any suggestions for clients which do not allow
the extra parameter?

Clients that don't support the extra parameter should be updated. Which clients are
you thinking of?