[vlc-devel] Regarding the HTTP POST implementation

[Steve Lhomme]

On 2019-10-06 17:20, Aniketh Girish wrote:
>     AFAIR, some devs wanted POST for some use cases, but I cannot
>     comment on their
>     behalf. 
> 
> 
> But if you wish to share what think off, I am more than happy to listen 
> to :)
> 
>     There is currently one POST usage in the audioscrobbler module.
> 
> 
> I see that.  Get's the payload and does a TLS_write()..
> 
> 
>      > Just another question that I had, why working on the
>     implementation of
>      > different HTTP methods differently?
> 
>     Useful APIs are rather different for GET than POST.
> 
>      > ie, why implementing PUT separately, and POST separately?
> 
>     PUT is used to write a file over the network.
>     POST is more of a toolkit for request/response messaging.
> 
>     The usage patterns and thus the API designs would be quite different.
> 
> 
> I understand.  But don't you think the HTTP functionalities should be 
> implemented as it is standardised to and change the way we use it rather 
> than developing HTTP functionalities for some specific use cases? What I 
> meant is that, design the HTTP API as meant, that is, GET gets us 
> something, POST sends over something etc. Thus, all the HTTP functions 
> does what it is supposed to do and the modules that use these methods 
> should design their callbacks and functions in a way that they can 
> incorporate the use cases within the module itself.  Also, doing a 
> TLS_write() to suggest HTTPS send a request with or without payload 
> seems confusing too. But what I suggest is an API, like 
> http_send_req(conn, req, body, bool TLS). With that bool, we can turn on 
> and off the TLS option??
> 
> Because I feel this way, we will never stop refactoring core design of 
> HTTP every time. I see there is already an old HTTP access and a new 
> one(access/HTTP).
> 
> What do you think? I have a small design document as well for this: 
> https://docs.google.com/document/d/1zenwBn_K8kb_hyNin5UALdOpZq6tBaHqkuR5WUMQ4Ko/edit?usp=sharing

That seems OK. I would merge the send_with_body() and send(). The body 
part being NULL if not needed.

The body part would be better handled as a feeding callback. The payload 
case being a simple use case with a basic callback. A callback might 
allow doing chunked transfer (low latency HLS/DASH).

It might also be good to have a callback providing extra HTTP headers 
(maybe Icecast could use that, OAuth authentication might be another use 
case).