When I try to do a search using www.corealty.com, it seems that the URL I get redirected to (given in the URL field) results in this message: An error has occured that prevents us from fulfilling your request. The webmaster will be notified of this error. We apologize for this inconvenience. If you can provide us with any additional information that would help us fix this problem, please send E-mail to: webmaster@corealty.com This error does NOT occur when I perform the same actions using Nova. So I think this is not a server-side error, but a problem with Necko somewhere. I am not sure what exactly is causing this, however.

Update: It seems even Netscape 4.x gives this error if you go directly to the URL. It works correctly however, when you click "Search" on the main page at http://www.corealty.com/ So I suspect this might be a cookie problem somehow, since obviously the server itself is expecting some information that it isn't getting... Anybody have any other clues?

->m12

looks like cookies to me too. Assigning to the cookies queen.

Not so fast. Gagan, have you convinced yourself that it is not an error with redirect that is causing the browser to mishandle cookies?

This is definitely not a cookie problem. There are no cookies being set, either with the 4.x browser or with seamonkey (turn on the cookie-warning pref to convince yourself of that). Below is the traffic that is being sent back to the server for each browser, starting from the time the search button is pressed. In the 4.x case the server responds by returning a valid page -- in the seamonkey case it returns the error page. 4.x browser: POST /cfm1/search1.cfm?id=creo HTTP/1.0 Referer: http://www.corealty.com/ Connection: Keep-Alive User-Agent: Mozilla/4.7 [en]C-NSCP (WinNT; U) Host: db.corealty.com Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 Content-type: application/x-www-form-urlencoded Content-length: 566 pmin_integer=The+minimum+price+entered+is+not+a+valid+number%21& pmax_integer=The+maximum+price+entered+is+not+a+valid+number%21& sqftmin_integer=The+square+footage+entered+is+not+a+valid+number%21& sqftmax_integer=The+square+footage+entered+is+not+a+valid+number%21& county=any&style=any&subdiv=&zipcode=&bedrms=& sqftmin=0&sqftmax=50000&baths=&street=& cities_required=Please+select+at+least+one+city+or+select+%27any%27%21& pmin_required=Please+enter+a+minimum+price%21& pmax_required=Please+enter+a+maximum+price%21& cities=Denver&pmin=175%2C000&pmax=200%2C000&=Searching seamonkey browser: POST /cfm1/search1.cfm?id=creo HTTP/1.0 host: db.corealty.com accept: */* user-agent: Mozilla/5.0 [en-US] (Windows_NT; I) referer: http://www.corealty.com/ Content-type: application/x-www-form-urlencoded; charset=ISO-8859-1 Content-Length: 566 pmin_integer=The+minimum+price+entered+is+not+a+valid+number%21& pmax_integer=The+maximum+price+entered+is+not+a+valid+number%21& sqftmin_integer=The+square+footage+entered+is+not+a+valid+number%21& sqftmax_integer=The+square+footage+entered+is+not+a+valid+number%21& county=any&style=any&subdiv=&zipcode=&bedrms=& sqftmin=0&sqftmax=50000&baths=&street=& cities_required=Please+select+at+least+one+city+or+select+%27any%27%21& pmin_required=Please+enter+a+minimum+price%21& pmax_required=Please+enter+a+maximum+price%21& cities=Denver&=Searching&pmin=175%2C000&pmax=200%2C000 Note in particular that the post data sent back to the site in the seamonkey case seems to be truncated; the "&=Searching" which was included in the 4.x case is missing. I would suspect that that may be what caused the problem. Note also that there is no cookie header sent back in either case.

Eric, could this be a dup of bug 12599 that you are looking at. Both seem to have to do with post data.

Reassigning to gagan. This looks like a server side redirect bug. Does only this site have problem? Or are all redirects broken?

The server's cgi doesn't like what we're sending. Could be the user agent, could be the charset attribute appended to the 5.0 request (this is actually most likely the problem). The reason we never turned this on (charset info) in 4.x was because it was going to break existing cgis. This becomes a question of whether or not we want to have webmasters fix their cgis to deal w/ the charset info (this is what *should* happen). Or, we succumb to broken cgis and stop sending charset info. There's another bug on this somewhere.

You are right Jud. I just verified that after bug 7533 this is not giving me any problems. So am going to mark this as fixed as well... Although I am not sure about the difference in the post data this may still be related to Eric's other bug. BTW we dont construct post data in the necko area, we just read off of the PostDataStream to which form elements are written to.

The post data is actually okay. The &=Searching appears in a different order, before pmin and pmax, but it is still there. It should come in the order 4.x sends it, so I'll look in to why it is not...

Yes, I noticed after I made the comment that the searching was there but in a different order. Sorry, I should have commented on that.

New bug created on this. See bug 18728.

verified per comments