Re: [Wish] should we remove the support for http redirections on initial PUT request?

[Matt Ward <[e-mail]>]

I think in a new server, architecture 2/decoupled will be favored by
experienced engineers such as yourself. I also think that adding support
for this protocol into existing media servers may lean more closely to
architecture 1/all-in-one.

Chrome follows 307s when sending a PUT by default. Do you know of an HTTP
client library that does not?

On Mon, Sep 13, 2021 at 10:13 AM Sergio Garcia Murillo <
[e-mail]> wrote:

>
>
> El lun, 13 sept 2021 a las 19:07, Matt Ward (<[e-mail]>) escribió:
>
>> I think this decision to require 307 support in a client is trading off
>> client and server complexity. I think the place to start answering this
>> question is to empathize with a couple different server architectures.
>>
>> 1- All-in-One - In this case all the pieces are bundled into a single
>> server. This means the WHIP endpoint/resource and the media server all
>> reside in a single process/process tree. Scaling is done by moving to
>> larger machines as Juliusz mentions they have done successfully. In this
>> case, a 307 from one server to another server makes scaling a bit easier.
>>
>> 2- Decoupled - In this case, the WHIP endpoint and media server are
>> decoupled and scaled independently. The WHIP endpoint is basically load
>> balanced the way most people approach this for API servers. In handling the
>> request for the WHIP endpoint, a media server is allocated + SDP crafted
>> directly in the WHIP endpoint. This allocation and SDP reply pointing to
>> the correct media server is the load balancing layer for this system and
>> therefore a 307 is not necessary.
>>
>> I'd expect a lot of implementations to follow closer to architecture 1
>> than 2, as this more closely aligns with what we see today in the open
>> source SFU space. If we believe this, we may desire keeping the 307
>> support. Web browsers support this without any additional effort (fetch
>> follows redirects just fine. Native clients may have a more diverse set of
>> HTTP stacks, but most of the iOS + Android apps I have worked on have no
>> problem at all following 307s.
>>
>>>
>>>
> I added the 307 redirection because I was going to implement 2) decoupled
> myself, but when implementing it, I found that it was much easier for me to
> just do a request from the balancer to the media server forwarding the SDP
> offer and sending back the sdp answer back to the client than sending the
> 307 redirect response. It would also be more effective as I can get rid of
> one round trip and avoid the client having the SDP twice.
>
> Regarding the support in libraries, please double check that the
> redirection is done with PUT and a body, because we have found that this
> may not be a common practice.
>
> Best regards
> Sergio
>
>
>
>