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

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Mon, 13 September 2021 17:13 UTC

MIME-Version: 1.0
References: <CA+ag07ZM3_UYYSZpRuyJ0ONy9g_C3sYYXVSqVEk-SdUK9tcPOQ@mail.gmail.com> <87fsu8foia.wl-jch@irif.fr> <CAABnt0Pr758_1dXnxUq1iD8br-9L6ktHvPGVj4FQBAxXi0iW6g@mail.gmail.com>
In-Reply-To: <CAABnt0Pr758_1dXnxUq1iD8br-9L6ktHvPGVj4FQBAxXi0iW6g@mail.gmail.com>
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Date: Mon, 13 Sep 2021 19:12:52 +0200
Message-ID: <CA+ag07bq08LbaH7uvx30nZELpJN+KS8EUpzjmi6k0zBRiYXhhA@mail.gmail.com>
To: Matt Ward <mattward@mux.com>
Cc: Juliusz Chroboczek <jch@irif.fr>, WISH List <wish@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000eddca905cbe39352"
Archived-At: <https://mailarchive.ietf.org/arch/msg/wish/Q6Uu9eOMU9LiGUv-qefWkvuLuy0>
Subject: Re: [Wish] should we remove the support for http redirections on initial PUT request?
Precedence: list

El lun, 13 sept 2021 a las 19:07, Matt Ward (<mattward@mux.com>) 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

[Wish] should we remove the support for http redi… Sergio Garcia Murillo
Re: [Wish] should we remove the support for http … Juliusz Chroboczek
Re: [Wish] should we remove the support for http … Matt Ward
Re: [Wish] should we remove the support for http … Sergio Garcia Murillo
Re: [Wish] should we remove the support for http … Matt Ward