Closed Bug 198309 Opened 21 years ago Closed 8 years ago

205 response should reset the content.

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: skasinathan, Assigned: skasinathan)

References

(
URL
)

Details

This is spin off from bug 49172. We should reset the content for a 205 response.
It seems like the right thing to do would be to catch the 205 response (maybe at
http://lxr.mozilla.org/seamonkey/source/uriloader/base/nsURILoader.cpp#205 ?)
and then iterate through *all* content in the document, looking for form
elements with IsContentOfType(), QI'ing to nsIFormControl, and calling Reset()
on the element.  You can't just go through document.forms because there can be
form controls that are not in a form.

Is this mainly an academic exercise for now, I presume?
Blocks: 65092
No longer blocks: 65092
It would be impressive if Mozilla took the lead on full HTTP support. Not just
"good enough", but stepping up to be the first browser to offer meaningful
support for "205 Reset Content" (reset data entry form), "301 Moved Permanently"
(offer to update bookmark, or do it automatically), and "410 Gone" (offer to
delete bookmark).

At worst, this is a prestige issue, so competitors have to continue trying to
catch up. At best, users and authors will more seriously leverage these features.
Brian, please try to specify what a 205 response should do, exactly.  Don't
forget the cases of multiple forms all on one page, a 205 response when a form
submission target is in a different window than the form, a 205 response to a
link click, etc.

Note that the HTTP spec doesn't really say what should happen on a 205.  Further
note that doing absolutely nothing is fully conformant to the HTTP specification.
"The server has fulfilled the request and the user agent SHOULD reset the
document view which caused the request to be sent. This response is primarily
intended to allow input for actions to take place via user input, followed by a
clearing of the form in which the input is given so that the user can easily
initiate another input action. The response MUST NOT include an entity."

-- http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.6

This seems fairly clear: call reset on all forms in the submitting document
(link or form), don't worry about formless controls (or else reset all controls
to default values as suggested in comment #1), don't worry about windows opened
or frames addressed by a form target (the author should know better). Those
latter special cases wouldn't work any differently than they do now, but simple
data entry apps could work more efficiently.
Again, I realize this is a SHOULD rather than a MUST. That was my point WRT "Not
just 'good enough', ..."
Brian, no need to quote the RFC section in its entirety.  We can all read it
(and have).

> This seems fairly clear

It's only clear if you assume that it should do what your use case demands.  For
example, why are you limiting the reset to forms?  The actual normative language
("reset the document view") sounds to me like what is meant is complete
restoration of the DOM to the state it was in when the page loaded (i.e., the
same thing that happens if a user click the "Reload" button, but with none of
the HTML <form> state restored).  Even if we decide that the "primarily
designed" language (which sounds informative to me) is meant to be a normative
definition, what is a "form"?  HTML <form> tags are clearly forms.  What about
XForms markup?  What about XBL bindings that implement form-like functionality
(and look just like HTML forms as far as the user can tell)?  What about the
same thing but without XBL (just done in JavaScript)?  What about Flash forms? 
What about Java applets with a form in them?

I realize that you're concerned about one narrow use case -- static page with a
single form on it.  But if we're going to implement some sort of behavior for
205 responses other than "do nothing", we need to make sure that behavior makes
sense for all pages Mozilla might be rendering.  So far, the most sensible
behavior I've seen specified in detail has been "do nothing."  If someone writes
up a clear specification of behavior here and that specification actually makes
sense, it may be worth thinking about implementing it.
For the record, I have no personal use case. I bring this up merely because this
seems like a simple implementation.

If resetting the DOM is simpler than resetting the individual forms, then great,
do that.

In the absence of a clear, normative specification or real usage, the first UA
to implement this functionality gets to be the de facto standard. This is the
incentive for spec writers to be as clear as possible.

* XForms have atomic forms that can be reset as simply as HTML forms. Maybe this
should be a consideration *after* XForms are supported, rather than an inertia
rationale.  ;)

* XBL widgets: reset or don't, whatever's easier. There should be no user
expectation here--they do not see the HTTP codes, so cannot distinguish a 200
from a 205.

* Flash and Java are replaced content. They may be reset only to the extent that
any replaced content may be.

A carefully considered examination for thousands of obscure and unlikely cases
would be merited if backward compatibility were an issue (or if there were real
controversy). Since no one is using 205 right now, and there is a great deal of
wiggle room in the spec, this seems like an opportunity to offer a simple
feature enhancement for developers. The spec itself appears to be fairly
"narrow" (if ill-defined). 

This is a very obscure feature, and I'm not losing any sleep over it, but what
is the point of spec authors ever including "SHOULD" if no one ever implements
anything but "MUST", out of fear of making the wrong decision?

205 Reset Content

Are you honestly maintaining that isn't perfectly clear?  :)
> bring this up merely because this seems like a simple implementation.

And I'm pointing out that 1) it's not clear what _should_ be implemented and 2)
no matter what, it's not simple to implement.

> the first UA to implement this functionality gets to be the de facto standard. 

Which means we have to do it right the first time.  Great.  ;)

> Maybe this should be a consideration *after* XForms are supported

You can download Mozilla builds with XForms supported right now.

> There should be no user expectation here

Define "user"?  For the HTTP implementation, the "user" is anyone making an HTTP
request.  That means the web page developer, say.

> They may be reset only to the extent that any replaced content may be.

Which isn't an answer to the question.

> but what is the point of spec authors ever including "SHOULD"

We implement plenty of SHOULDs. When they make sense.  This one doesn't, so far.

> Are you honestly maintaining that isn't perfectly clear?  :)

Absolutely.  If you think it is, I invite you to attempt to implement it in a
reasonable way.  The mozilla source is there for the coding if you want.

See step eight of:
   http://whatwg.org/specs/web-forms/current-work/#form-submission

If you think that's not well-defined, then e-mail whatwg@whatwg.org.
(In reply to comment #8)
> And I'm pointing out that 1) it's not clear what _should_ be implemented and 2)
> no matter what, it's not simple to implement.

1. From comment #6, "sounds to me like what is meant is complete restoration of
the DOM to the state it was in when the page loaded" it appears that it's clear
enough to you. It seems to me that "Reset Content" should reset the content. I'm
not sure where the ambiguity is.

2. You've stated that this would not be simple to implement, but not supported
this conclusion.

> Define "user"?  For the HTTP implementation, the "user" is anyone making an HTTP
> request.  That means the web page developer, say.

For semantic clarification: "user" is someone using the software, "author" is
someone who writes content for the software, as in the sentence: 'Good authors
should test their assumptions about functionality before publishing.'  ;)

> > They may be reset only to the extent that any replaced content may be.
> 
> Which isn't an answer to the question.

Sure it is: Can we reset replaced content? Yes? Then we should do that. :)

> > but what is the point of spec authors ever including "SHOULD"
> 
> We implement plenty of SHOULDs. When they make sense.  This one doesn't, so far.

Is that a general consensus? It sounds kind of unilateral.

My point here, I guess, is that the "SHOULD" status alone need not be an
argument against implementation.

> > Are you honestly maintaining that isn't perfectly clear?  :)
> 
> Absolutely.  If you think it is, I invite you to attempt to implement it in a
> reasonable way.  The mozilla source is there for the coding if you want.

Snarky! Look, I'm not losing sleep over this, it just seemed easy to reset the
document's forms. If this is too much trouble, maybe this should be marked
WONTFIX so people can concentrate on other things. I just have a hard time
seeing any dubiety, or how implementation would require any more time or effort
than this conversation. ;)
> it appears that it's clear enough to you

No, that wording was merely the closest I could come to what the spec seems to
say...  It can't be what the spec means (especially since it then talks about
resetting forms, which is a totally different operation with radically different
results).

> 2. You've stated that this would not be simple to implement, but not supported
> this conclusion.

I'm stating this based on my knowledge of the code.  I, in my capacity as module
peer for the relevant Mozilla modules, don't see a simple way to implement this.
 If you do, please provide patches.

> Sure it is: Can we reset replaced content? Yes? Then we should do that. :)

Define "reset", please.  And define "replaced content", for that matter, in this
context.

> Is that a general consensus? It sounds kind of unilateral.

That's my opinion, not a policy statement.

> I guess, is that the "SHOULD" status alone need not be an
> argument against implementation.

Agreed, if there is something specific and agreed-on to implement.
(In reply to comment #11)
> No, that wording was merely the closest I could come to what the spec seems to
> say...  It can't be what the spec means (especially since it then talks about
> resetting forms, which is a totally different operation with radically different
> results).

If you have time, could you elaborate on these differences?

> I, in my capacity as module
> peer for the relevant Mozilla modules, don't see a simple way to implement this.

That's unfortunate. :(

> > Sure it is: Can we reset replaced content? Yes? Then we should do that. :)
> 
> Define "reset", please.  And define "replaced content", for that matter, in this
> context.

Reset: re-initialize or re-activate, as if reloaded from cache.
Replaced content: <object>s, which typically have a minimal DOM interface.

> Agreed, if there is something specific and agreed-on to implement.

Does the WHAT-WG spec mentioned earlier disambiguate the situation at all?
Is there a formal process for agreeing on the meaning of the spec, i.e. voting?
I guess since the spec is quite clear about the *intent* of the code...

"This response is primarily intended to allow input for actions to take place
via user input, followed by a clearing of the form in which the input is given
so that the user can easily initiate another input action."

...I feel the question ought to be 'How can this goal be achieved?'

If simply resetting the forms/XForms in the document accomplishes this end, then
isn't that the right implementation decision? Other relevant possibilities
include reloading the document from cache, or iteratively resetting all components.

If your assertion is that this is too hard, that's fine--it will wait until
someone that actually needs it is motivated to implement it. However, doing
nothing because there isn't specific code available that makes all the design
decisions definitely does not produce the desired effect. :)
205 is not a defacto thing
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.