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

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 13 Sep 2021 16:44:26 +0200

Hi all,

On the draft, it is stated that:

WHIP endpoints and media servers MAY not be colocated on the same server so
it is possible to load balance incoming requests to different media
servers. WHIP clients SHALL support HTTP redirection via 307 Temporary
Redirect response code.

However, http clients are not handling the redirection automatically as it
is a PUT request with body and not a GET request. I am not sure if
supporting this makes much sense anymore, does anyone plan to use it or we
should remove it from the draft?

Best regards
Sergio

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 13 Sep 2021 18:07:09 +0200

> However, http clients are not handling the redirection automatically as it is a
> PUT request with body and not a GET request. I am not sure if supporting this
> makes much sense anymore, does anyone plan to use it or we should remove it
> from the draft?

Galene's native protocol supports redirecting a login to a different
server, which is useful when migrating a group between servers.  We have
found this useful when a seminar during lockdown turned out to be more
popular than expected, and we needed to do a last-minute migration to
a larger server.

Perhaps we should be doing load-balancing at a lower level, but the
ability to redirect the initial request is something I'm definitely going
to implement.  On the other hand, I'd have no objection to requiring that
the client resend the initial request when it gets redirected.

-- Juliusz

---

From: Matt Ward <[email-masked]>
Date: Mon, 13 Sep 2021 10:07:02 -0700

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.

On Mon, Sep 13, 2021 at 9:07 AM Juliusz Chroboczek <[email-masked]> wrote:

> --
> Wish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wish
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 13 Sep 2021 19:12:52 +0200

El lun, 13 sept 2021 a las 19:07, Matt Ward (<[email-masked]>) escribió:

> 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

---

From: Matt Ward <[email-masked]>
Date: Mon, 13 Sep 2021 10:36:31 -0700

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?