Closed Bug 49172 Opened 24 years ago Closed 21 years ago

Browser fails to respond correctly to a 205 (reset) status.

Categories

(Core :: Networking: HTTP, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.4alpha

People

(Reporter: isoma, Assigned: skasinathan)

References

()

Details

(Whiteboard: [http/1.1])

Attachments

(1 file)

http://www.compsoc.man.ac.uk/~isoma/spare/205test is a simple form configured to
POST to http://www.compsoc.man.ac.uk/~isoma/spare/cgi/205status

http://www.compsoc.man.ac.uk/~isoma/spare/cgi/205status is a very basic CGI
consisting of:
#!/bin/bash

echo Status: 205 Reset form
echo Content-type: application/octet-stream
echo

...on this server, this results in the following response headers:
HTTP/1.1 205 Reset form
Date: Wed, 16 Aug 2000 14:14:17 GMT
Server: Apache/1.3.12 (Unix) PHP/4.0.0
Content-Location: 205status.cgi
TCN: choice
Vary: negotiate
X-Powered-by: Steam
Cache-Control: max-age=86400
Expires: Thu, 17 Aug 2000 14:14:17 GMT
Connection: close
Content-Type: application/octet-stream


According to RFC 2616, an HTTP/1.1 conforming user agent should reset the
content of the form to the freshly-loaded state on receipt of a 205 status code.

Although there is no entity in the response from
http://www.compsoc.man.ac.uk/~isoma/spare/cgi/205status Mozilla pops up a
download select dialogue box, presumably because of the Content-type: header. 
The form is not reset.
->ruslan
Assignee: gagan → ruslan
Target Milestone: --- → Future
setting bug status to New
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
pulling in ruslan's necko bugs ->darin
Assignee: ruslan → gagan
Status: ASSIGNED → NEW
Target Milestone: Future → M19
this will need some cleaning out of the elements from the layout/dom side as 
well. 
Assignee: gagan → darin
Target Milestone: --- → Future
mass move, v2.
qa to me.
QA Contact: tever → benc
*** Bug 119990 has been marked as a duplicate of this bug. ***
Severity: trivial → normal
Status: NEW → ASSIGNED
Component: Networking → Networking: HTTP
Priority: P3 → --
Whiteboard: [http/1.1]
Target Milestone: Future → mozilla1.4alpha
-> suresh

there is some code in uriloader/base/something that handles 204.
Assignee: darin → suresh
Status: ASSIGNED → NEW
hmm...using NS4.8 and IE, this testcase brings up the dialog something like "The
document contains no data". Is this the correct behaviour or something got
changed in the testcase?
Status: NEW → ASSIGNED
suresh: 205 is a HTTP/1.1 response code, so NS4x would not understand it.  also,
IE does not seem to honor it either.  you might want to see if opera or
konqueror/safari get it right.
Opera 7.02 does not handle 205 correctly either. It does not reset the form (i.e
I think it behaves like 204) and it doesn't bring up any downlaod dialog (as
mozilla does) or "document contains no data" (like IE does).

Using Safari 1.0, clicking on a submit brings up an empty page (no other dialogs
though).
Attached patch patchSplinter Review
This patch makes 205 response to behave like 204 response.
Comment on attachment 116859 [details] [diff] [review]
patch

sr=darin

yeah, we should at least get this in and then worry about full compliance.  thx
suresh!
Attachment #116859 - Flags: superreview+
Attachment #116859 - Flags: review?(dougt)
Comment on attachment 116859 [details] [diff] [review]
patch

drop the extra space between ')' and "or"

+  // - In the case of a 204 (No Content)  or
Attachment #116859 - Flags: review?(dougt) → review+
this is fixed in trunk.

file a new bug 198309 to address the actual content reset issue.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: