14702 - [DOGFOOD]An error has occured that prevents us from fulfilling . . .

Status: VERIFIED FIXED

(Core :: Networking: Cookies, defect, P3)

Description

[Daniel Roberts]

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:
[e-mail]

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.

Comment 1

[Daniel Roberts]

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?

Comment 2

[chris hofmann]

->m12

Comment 3

[Gagan]

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

Comment 4

[Stephen P. Morse]

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

Comment 5

[Stephen P. Morse]

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.

Comment 6

[Stephen P. Morse]

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

Comment 7

[leger]

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

Comment 8

[Judson Valeski]

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.

Comment 9

[Gagan]

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.

Comment 10

[Eric Pollmann]

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...

Comment 11

[Stephen P. Morse]

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.

Comment 12

[Eric Pollmann]

New bug created on this.  See bug 18728.

Comment 13

[Tom Everingham]

verified per comments