Subject: Re: [Netconf] how to handle XML parse errors

From: "Andy Bierman" <[email-masked]>
Date: Wed, 18 Aug 2010 11:11:34 -0700

I disagree.  This is valid XML content, so the server cannot ignore the XML and just look for some string.  This could be leaf content instead of the frame start msg.

Andy

----- Reply message -----
From: "Phil Shafer" <[email-masked]>
Date: Wed, Aug 18, 2010 10:11
Subject: [Netconf] how to handle XML parse errors
To: "Andy Bierman" <[email-masked]>
Cc: "Kent Watsen" <[email-masked]>, "Juergen Schoenwaelder" <[email-masked]>, "[email-masked]" <[email-masked]>

"=?utf-8?B?QW5keSBCaWVybWFu?=" writes:
>AFAIK, there is no way to put chars in the XML stream for framing, so there is
>no point in changing 4742.

The transport encoding can insert whatever is needed.  For example, I
could define a framing protocol that inserts "#Frame-length" messages
into the text, and "#End-of-frame" at the end of a message.  There
would be no confusion about when a message ends and no overlap between
content and framing.

#Frame-length: 1024
.... 1024 bytes of content
#Frame-length: 1024
.... 1024 bytes of content
#Frame-length: 56
.... 56 bytes of content
#End-of-frame

The "write" code is simple:

    fprintf(fp, "#Frame-length: %u\n%s", strlen(msg), msg);

and the reading code is similarly simple.  End-of-frame detection
is simple and robust.

If I want to manually construct data, I can calculate the length and add the
it statically to the top of my file, and if I want to cut-n-parse, I can
make a perl function to do this framing for me.

Yeah, I know; none of this is news and I've begged for this before,
but somehow I just couldn't stop myself.

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 18 Aug 2010 11:30:23 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Phil Shafer" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, August 18, 2010 11:11 AM
> Subject: Re: [Netconf] how to handle XML parse errors
>
> I disagree.  This is valid XML content, so the server cannot ignore the
> XML and just look for some string.  This could be leaf content instead
> of the frame start msg.

For recovery purposes the framing needs to be considered a distinct
layer from the content processing.

When the content layer gets confused or lost, it needs to defer to
the framing layer, which should be designed so that it can't be tripped
up by the content. Encapsulation with explicit lengths is an easy
way to do this, as has already been suggested.

This still leaves the possibility of something going wrong at the
layer doing the framing, but terminating the association is a reasonable
response when the framing layer gets confused.

In Netconf, as long as framing and content processing remain entwined,
this leads to the conclusion that if some kind of framing / bracketing
error is detected, the safest response is to end the connection.

Randy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 18 Aug 2010 14:17:18 -0400

"=?utf-8?B?QW5keSBCaWVybWFu?=" writes:
>I disagree.  This is valid XML content, so the server cannot ignore the XML and
>just look for some string.  This could be leaf content instead of the frame
>start msg.

I think you've missed my content completely.  Most likely a
framing error.  ;^)

In my code, when I go to write data to an ssh connection, I can
easily find the length of the data and prepend that data with
"#Frame-length: ", the number of bytes of data, and a newline.  When
I'm at the end of the data, I can easily send the string "#End-of-frame"
and a newline.

When I'm ready to read data, I can read a line of inline, inspect
that line and see if it begins with "#Frame-length: ".  If it does,
then I can learn the number of bytes that follow, and then proceed
to read that number of bytes.  This data can then be passed to an
upper layer as XML data (without the "#Frame.*" line). If the line
is "#End-of-frame", then I can tell the upper layer and I've seen
the end of the frame, which will translate into something similar
to EOF.

There's no escaping of data, no relying on the data to provide
the framing, and no interaction between the framing and the
content.

Thanks,
 Phil