Review Request 116017: Implement POST -> POST redirection support in KIO

[David Faure]

> On Feb. 24, 2014, 7:17 p.m., David Faure wrote:
> > kio/kio/job.h, line 307
> > <https://git.reviewboard.kde.org/r/116017/diff/1/?file=245840#file245840line307>
> >
> >     "recommended you use the function for when..." - rather unclear. Which function? In the commit log you said you wanted to encourage using the QIODevice overload directly (which I assume this is trying to do, although not clearly).
> >     
> >     But even then I don't think it makes sense. Anyone who has a QByteArray on their hands should call the function with a QByteArray rather than just create a QBuffer in order to be able to call the "recommended function" -- all this achieves is duplicating that bit of code into the apps.
> >     
> >     I would suggest removing the whole note, simply. Two overloads = pick the most convenient one for the calling code.
> >
> 
> Dawit Alemayehu wrote:
>     Well the intent was to discourage people from using QByteArrays to store upload data in the first place so as to avoid the same mistake committed in KHTML. Currently KHTML stores the contents of an entire file, no matter how large, into memory whenever a user attempts to upload such files. My attempt to get the KHTML developers to realize that is the wrong thing to do did not get anywhere. Anyways, you are correct. It is pointless to attempt to discourage people from using API that has been available since the creation of KIO.

Oh, I agree. If one can provide the data as a QIODevice that retrieves data on demand that is indeed much better.

But simply deprecating the method that takes a QByteArray will lead to absurdity for people who actually have a QByteArray in the first place and no other choice: they'd have to create a QBuffer around it just to call the right method, that's just inconvenient.

However I agree - if one has a choice, one should prefer not to create a qbytearray with the full data in the first place.

"has been available since the creation of kio" isn't at all any reason for or against, times change and things improve :) We deprecate things for a good reason. I just don't think there's a good reason to deprecate the QByteArray overload. At most it can say in its documentation "if you can, try not to load the full data upfront, and use the QIODevice overload instead".


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116017/#review50701
-----------------------------------------------------------


On Feb. 27, 2014, 1:41 p.m., Dawit Alemayehu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/116017/
> -----------------------------------------------------------
> 
> (Updated Feb. 27, 2014, 1:41 p.m.)
> 
> 
> Review request for kdelibs, Andrea Iacovitti and David Faure.
> 
> 
> Bugs: 330890
>     http://bugs.kde.org/show_bug.cgi?id=330890
> 
> 
> Repository: kdelibs
> 
> 
> Description
> -------
> 
> The attached patch implements support for redirecting one POST request to another in KIO. Unless implicitly disabled currently the automatic redirection handler in KIO always redirects any POST requests to a GET.
> 
> Note this patch also changes the original KIO::http_post implementation that accepted a QByteArray to simply store the data in a QBuffer and call the newer implementation that uses a QIODevice. I have updated the documentation for the original implementation to state as such and encourage developers to directly use the newer http_post method instead. Not sure if everyone will agree with my implementation but it makes it much easier to resend POST data on redirection.
> 
> 
> Diffs
> -----
> 
>   kioslave/http/http.cpp 9eba5d1 
>   kio/kio/job_p.h 5ead3ed 
>   kio/kio/job.h aeaffa2 
>   kio/kio/job.cpp edc5fed 
> 
> Diff: https://git.reviewboard.kde.org/r/116017/diff/
> 
> 
> Testing
> -------
> 
> http://greenbytes.de/tech/tc/httpredirects/t307methods.html
> http://greenbytes.de/tech/tc/httpredirects/t308methods.html
> http://www.w3.org/People/Bos/Test/redirect307.html
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20140227/e9587fc9/attachment.htm>