On 2016-06-18 05:09, xinglp wrote:
> 2016-06-17 23:31 GMT+08:00 Felix Fietkau <n...@nbd.name>:
>> On 2016-06-17 13:19, xinglp wrote:
>>> --post-file parameter only support text file not binary file.
>>> "Content-Length" is more compatible to the http server world.
>> Your patch cannot apply due to whitespace damage. Also, the library
>> supports delivering POST data in multiple calls to send_data - your
>> patch is breaking that completely.
> Now, there is an attachment.
I would recommend using git send-email to avoid such issues in the future.
> I saw uclient_http_send_data() was only called once in
> uclient-2016-06-16, what did I missed ?
What you missed is the fact uclient-fetch is not the only user of the
library code. The uclient library is used in a few other projects as
well, some of which are not in the LEDE tree yet.
Please make sure that any change you come up with to support --post-file
does not break the library API.
>> If you want to support using content_length instead of chunked encoding,
>> please do so in an optional way that does not break the existing code.
> That's a easy work, but where the multiple calls to send_data is
> needed on earth, wget does not use that at all.
If you upload a large file, it makes sense to not need to have it in
memory completely.
>> Could you please also provide some information why you're replacing
>> chunked encoding with content-length? What servers do not accept this?
> Some APPs's server side are "homemade" http server, which may not
> support client to server chunked encoding transport.
> And most of the browsers use content-length to post data, I only saw
> chunked encoding was used in server to client transport.
>> And why are you saying it "only support text file not binary file"?
> Check this:
> uclient-fetch.c line 337
> if (post_data) {
> uclient_http_set_header(cl, "Content-Type",
> "application/x-www-form-urlencoded");
> uclient_write(cl, post_data, strlen(post_data));
> }
Ah, okay. I was confused for a moment because you wrote "--post-file" in
that sentence in the original description.
- Felix
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
