Closed Bug 49172 Opened 24 years ago Closed 22 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: 22 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: