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)
Tracking
()
RESOLVED
FIXED
mozilla1.4alpha
People
(Reporter: isoma, Assigned: skasinathan)
References
()
Details
(Whiteboard: [http/1.1])
Attachments
(1 file)
928 bytes,
patch
|
dougt
:
review+
darin.moz
:
superreview+
|
Details | Diff | Splinter Review |
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.
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
Comment 6•23 years ago
|
||
*** Bug 119990 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Severity: trivial → normal
Status: NEW → ASSIGNED
Component: Networking → Networking: HTTP
Priority: P3 → --
Whiteboard: [http/1.1]
Target Milestone: Future → mozilla1.4alpha
Comment 7•21 years ago
|
||
-> 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
Comment 9•21 years ago
|
||
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.
Assignee | ||
Comment 10•21 years ago
|
||
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).
Assignee | ||
Comment 11•21 years ago
|
||
This patch makes 205 response to behave like 204 response.
Comment 12•21 years ago
|
||
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 13•21 years ago
|
||
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+
Assignee | ||
Comment 14•21 years ago
|
||
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.
Description
•