[vlc-devel] [PATCH] network: implement an API for HTTP requests.

Rémi Denis-Courmont remi at remlab.net
Tue Feb 4 11:16:27 CET 2014


On Tue, 4 Feb 2014 10:53:59 +0100, Felix Abecassis
<felix.abecassis at gmail.com> wrote:
> 2014-02-03 Rémi Denis-Courmont <remi at remlab.net>:
>>
>> All I am saying is that you cannot just block the calling thread with
no
>> way
>> out. There are two separate underlying issues. First you need to time
>> out if
>> the server does not answer in a reasonable time line. Second, the
calling
>> thread needs a way to not get stuck for an arbitrarily long time if it
>> needs
>> to abort (such as because VLC is quitting).
>>
>> How you solve this issue is an implementation choice. The current Lua
>> net code
>> is just one solution, that fits perhaps relatively well with the Lua
>> interpreter. Here you have different constraints, since the API is not
>> tied to
>> Lua.
> Thank you for the clarification. This non-blocking behavior is indeed
> required.
> 
>> What if the response is redirected? What if the server is version 0.9?
> 
>> What if the body size is not specified (i.e. no Content-Length)?
>> Also what if the body size is insanely large?
> 
>> What about transfer encoding?
>>
>> With all those mistakes, I have to believe you did not read RFC2616...
> I'm aware of all this but this is still WIP (the tag is missing, my
> mistake). Also, the goal is not necessarily to implement the complete
> RFC for now. For instance we could let the user handle the 3xx status
> codes for now.

The point is not the complete RFC; nobody implements the complete RFC. The
point is to implement the mandatory features so that you get a minimum
safe, secure and *interoperable* implementation. You cannot expect the
server, say, to specify a Content-Length, just because you wish it did.

> You are right that there are a few missing cases here when handling
> the response and we shouldn't make any assumption on what we might
> receive, but I wanted to send a new (incomplete) iteration for review
> since the patch is already pretty large.

-- 
Rémi Denis-Courmont
Sent from my collocated server



More information about the vlc-devel mailing list