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

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 <jch@irif.fr> wrote:

> > 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
>
> --
> Wish mailing list
> Wish@ietf.org
> https://www.ietf.org/mailman/listinfo/wish
>