[PATCH] HTTP ioslave keeping POST data when it shouldn't

[Dawit A.]

On Thursday 13 June 2002 19:37, Dawit A. wrote:
> On Thursday 13 June 2002 09:42, Best, Jan-Pascal van wrote:
> > On June 12, Dawit A.  wrote:
> > > On Tuesday 11 June 2002 10:11, Best, Jan-Pascal van wrote:
> > > > Hi all (especially Dawit),
> > > >
> > > > Just found the patch by Dawit about persistent connections.
> > >
> > > It almost
> > >
> > > > solves my problem, in that it resets the POST buffer in some
> > > > circumstances and I'd like it to do that in more circumstances,
> > > > especially after webdav queries. It seems like the check
> > >
> > > for HTTP_POST
> > >
> > > > is not necessary. If it is removed, my webdav trouble disappears.
> > > > Authentication for webdav still works now.
> > >
> > > Nope, feel free to apply.  The check for the request method
> > > is a vestage from
> > > the days when kio_http only dealt with the original HTTP
> > > protocol and not WebDAV as well :)
> >
> > There's still a problem with this. Some methods, like listDir,
> > for webdav set m_bufPOST to some document to be sent, before calling
> > httpOpen(). Now httpOpen calls resetConnectionSettings, which
> > clears m_bufPOST because it thinks it's a relic from another
> > session.
> >
> > Would it be a good idea to put a flag in HTTPRequest
> > that orders resetConnectionSettings to leave alone
> > m_bufPOST? This flag could be set by the appropriate DAV member
> > functions of HTTPProtocol and also by readHeader(), when it
> > receives a 401 or 407. After use, it is reset by
> > resetConnectionSettings() and also in resetSessionSettings().
> >
> > What do you think?
>
> Come to think of it you are correct this does not work for HTTP at all
> either if the connection with the site has to be re-established before
> posting the data!  I now know why I originally moved it into ::readHeader
> :)  I will fix this the correct way.  There is no need for yet another
> flag...

This should be fixed now.  Please try it and let me know if it works for you.
Thanks.

Regards,
Dawit A.