You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/03/12 12:49:19 UTC
very weird sitemap error handling behavior
I'm currently focusing on error handling and I found a weird behavior by
messing around with the <handle-errors> subpipe.
I wrote
<map:handle-errors>
<map:serialize type="xml"/>
</map:handle-errors>
in my sitemap to see what the error-notify generator was emitting, but
Camino (formerly chimera, aka mozilla-light for macosX) which now has
pretty nice (nicer than IE, for that matter) built-in XML support,
complains that the XML is invalid.
In fact, I get
<?xml version="1.0" encoding="UTF-8"?>
<error:notify>[snip]</error:notify>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>[the rest]</html>
Strangely enough, the contents appended are the correct result of the
xslt transformation, even if the welcome.xml page to generate has been
manually altered to be non-well-formed and trigger the error.
it seems that:
1) the parser spits the events down the pipeline even if non-wellformed
content is found
2) thus the XSLT processing is still performed
3) but the exception is somewhat signaled
4) so the error notifier kicks in
5) but forget to close the output stream right after the error notification.
Now, is this a bug or a feature? [I personally don't think that cocoon
should even emit non-well-formed content, so I would consider this a
bug, but maybe there is something I overlooked]
comments?
Chunked Encoding (Was: very weird sitemap error handling behavior)
Posted by Santiago Gala <sg...@hisitech.com>.
Nicola Ken Barozzi wrote:
(...)
>
> You came up with clever ideas about resetting via HTTP or something
> like that (chunking?) but I'm not able to understand a thing about
> it.
>
From http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html
> The chunked encoding modifies the body of a message in order to
> transfer it as a series of chunks, each with its own size indicator,
> followed by an OPTIONAL trailer containing entity-header fields. This
> allows dynamically produced content to be transferred along with the
> information necessary for the recipient to verify that it has
> received the full message.
This will allow Cocoon to start "pipelining" a valid response to the
client, in chunks of server controlled size, and use the optional final
trailer:
> The trailer allows the sender to include additional HTTP header
> fields at the end of the message.
>
at the end, for instance for incremental computation of the
Content-Length or MD5, for instance.
WRT using the trailer for error handling, it puzzles me if there is any
way to do it as chunked transfer encoding does *not* allow changing the
status code. It is intended as a "latency killer" feature, and also to
enable computation of length and md5 without having to cache the whole
answer. It would be great in the "proxy friendly" thread, though.
Regards,
Santiago
RE: very weird sitemap error handling behavior
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
> Generally speaking this is not true. Cocoon can emit non-wellformed
> content, but it should look like:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> <html>[the rest]</html>
> <error:notify>[snip]</error:notify>
>
> This is because we don't want to buffer all the response for percieved
> speed reasons (and also debugging too, it's easy to see where it stops).
>
But we also implemented the buffering for debugging. AFAIK, the buffering
is activated by default, so if an error occurs, nothing of the original
pipeline is really written to the client.
If this is currently the case, than we have another bug as well.
Carsten
Re: very weird sitemap error handling behavior
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 12/03/2003 12.49:
...
> In fact, I get
>
> <?xml version="1.0" encoding="UTF-8"?>
> <error:notify>[snip]</error:notify>
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> <html>[the rest]</html>
>
> Strangely enough, the contents appended are the correct result of the
> xslt transformation, even if the welcome.xml page to generate has been
> manually altered to be non-well-formed and trigger the error.
>
> it seems that:
>
> 1) the parser spits the events down the pipeline even if non-wellformed
> content is found
> 2) thus the XSLT processing is still performed
> 3) but the exception is somewhat signaled
> 4) so the error notifier kicks in
> 5) but forget to close the output stream right after the error
> notification.
>
> Now, is this a bug or a feature?
IMHO a bug.
If there is an error, the pipeline should stop dead cold and hand all to
the handle-errors part of the pipeline.
One thing though is if that is an error or a warning, in that case the
handle-errors should not even be called.
Either way, it's a bug.
> [I personally don't think that cocoon
> should even emit non-well-formed content, so I would consider this a
> bug, but maybe there is something I overlooked]
Generally speaking this is not true. Cocoon can emit non-wellformed
content, but it should look like:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>[the rest]</html>
<error:notify>[snip]</error:notify>
This is because we don't want to buffer all the response for percieved
speed reasons (and also debugging too, it's easy to see where it stops).
You came up with clever ideas about resetting via HTTP or something like
that (chunking?) but I'm not able to understand a thing about it.
So currently with errors Cocoon is by design not giving well-formed
content, but it's not your bug it seems, which looks real.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------