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)
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•22 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•22 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•22 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•22 years ago
|
||
This patch makes 205 response to behave like 204 response.
Comment 12•22 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•22 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•22 years ago
|
||
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.
Description
•