Closed Bug 14702 Opened 21 years ago Closed 20 years ago

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

Categories

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

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: zuperdee, Assigned: gagan)

References

()

Details

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.
Target Milestone: M11
Component: Necko → Cookies
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?
Target Milestone: M11 → M12
->m12
Assignee: gagan → neeti
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?
Assignee: neeti → morse
Summary: An error has occured that prevents us from fulfilling . . . → [DOGFOOD]An error has occured that prevents us from fulfilling . . .
Status: NEW → ASSIGNED
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?
Assignee: morse → gagan
Status: ASSIGNED → NEW
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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.