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

[Felix Abecassis]

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.

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.


-- 
Félix Abecassis
http://felix.abecassis.me