I don't think this is new to CVS, but I don't have a copy of 0.8.1 handy, and CVS history still scares me ;) It's at the end of Page.respond, where if no actions are found it calls defaultAction --
Yeah, I checked. It's not there. Only actions registered in actions() are looked for and/or executed. There's no "defaultAction" anywhere in WebKit.
We're still not ending the response. We're still sending a response. It's shorter, yes, but we're still doing it. "End" is the wrong metaphor.
We are sending a response, but at the same time we're ending the response. Once you've sent the redirect there's no point ot sending anything else.
Now, it seems that we're splitting hairs. ;-) I would say that by your definition, all responses are "ended" eventually. Oh well.
Technically, one can send a redirect header AND an html page, but that may actually break the rules. Webkit allows it, and probably Apache passes it through, but it may be against spec. My argument is that a redirect *IS* the response; "ending" it is redundant.
Theory aside (I'll stop whining about this now), I definitely agree that there's no point in sending anything else after you send a redirect, which is why I want to *conditionalize* writeHTML in most cases.
I supose we have to let someone disrupt response, but then you have the possibility of having sent data to a stream that is never sent, which is weird. An example: we use a "messages" and "errors" pattern, much like what's in your sandbox. We pop them from a list in session and send them in writeHTML. If they get sent, and *then* the response is converted into a redirect, the message is lost. This is why response should be either/or.
Yes, I've thought about that issue. Generally I never redirect after I'm part way through rendering a page, but other people might want to do that.
There should be a way to detect that the output is being thrown away. Using the component stuff you actually could get an exception event, and perhaps infer that the output is being thrown away.
If you *want* that behavior, by all means, you should be allowed to do so. But, sane-defaults/best-practices, whatever you want to call it, I say that writeHTML() shouldn't be called if a redirect is already there when you start respond(). Obviously, if you raise it in the middle of writeHTML, it's different.
I like the idea of an exception being thrown to warn us, and of course, we could always catch it and ignore it.
------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
