DavidSchinazi / draft-cms-masque-connect-ip

Other
2 stars 1 forks source link

No fixed resource #13

Closed martinthomson closed 3 years ago

martinthomson commented 3 years ago

Let the URI address any resource on the origin server/MASQUE proxy (these are the same thing here anyway), don't force the most precious resource ("/") to handle all this CONNECT-IP gunk.

The design does not truly depend on any information being conveyed in the CONNECT-IP request. All the IP allocation and whatnot is done inside the stream.

As noted in other issues, there might be ways to use the resource identity to distinguish features or treatment. Allowing CONNECT-IP on any resource would enable that style of "negotiation".

The cost is that your configuration for this changes from a hostname to a URL. But that's not such a big deal.

DavidSchinazi commented 3 years ago

That makes sense to me. Perhaps we can say

achernya commented 3 years ago

Upon reflection, is there any reason to not support URIs for the CONNECT-IP method? That way you could scope the CONNECT-IP to different "profiles" behind different URIs. That would be more powerful than just requiring headers / vhosting to have multiple CONNECT-IP instances. Maybe we should go one step further and add support for this in the draft, rather than having it be controlled by future extensions? It doesn't seem like a lot more work to do it up front.

DavidSchinazi commented 3 years ago

That's a good point. Maybe we just say that path MUST NOT be empty and let individual deployments have their own semantics. In hindsight that's what other HTTP methods do.

achernya commented 3 years ago

Right, whereas when we wrote this initially, we were in the CONNECT-UDP mindset, where the connection is to a different endpoint, where as here, the CONNECT-IP is to the proxy itself. We inherited the wrong semantics.