Re: [xml] Potential problem with 2.7.4

[Mike Hommey <mh glandium org>]

On Tue, Sep 15, 2009 at 08:28:19PM +0200, Daniel Veillard wrote:
> On Tue, Sep 15, 2009 at 07:57:17PM +0200, Mike Hommey wrote:
> > On Tue, Sep 15, 2009 at 07:43:54PM +0200, Daniel Veillard wrote:
> > >   Some application don't deliver sufficient data at start of parsing
> > > conflicting with the fix I made for 
> > >
> > >   https://bugzilla.gnome.org/show_bug.cgi?id=566012 
> > >
> > > I commited a fix which solves the problem while preserving the EBCDIC
> > > parsing fix:
> > >
> > > http://git.gnome.org/cgit/libxml2/commit/?id=9d3d141c412baa5c713ad3df48f1a4d179e07b05
> >
> > +     * than just the first line, unless the amount of data is really
> > +     * too small to hold "<?xml version="1.0" encoding="foo"
> >       */
> > +    if ((ctxt->input->end - ctxt->input->cur) < 35) {
> > +       GROW;
> > +    }
> >
> > Can't there be another similar problem later in the code when that GROW
> > still doesn't get enough to hold "<?xml version="1.0" encoding="foo" ?
>
>   It's a trade-off, basically the first line is nasty because you have
> to guess an encoding and only at the end of the first line you can
> actually be sure you use the right decoder. If you push too agressively
> the risk is to corrupt the first bytes of the content as 566012
> demonstrated.
>
>   basically if in 2 calls to GROW you didnt got enough for the first
> line well yes you're at risk, but IMHO the client side is fairly broken
> then.

But there's nothing that needs the input callback to give back enough
input. It could even give back data a byte at a time. Wouldn't a better
solution to revert the current fix and to have xmlParserInputBufferGrow
actually fill len bytes by looping over in->readcallback until the
callback either gives enough data or says there's nothing more ?

Mike