Nicolas, you're absolutely right. Deploying something that isn't part of the commonly accepted subset of HTTP/1.1 over port 80 doesn't work. As an example, if you attempt to use a different entity-body compression, for instance (something explicitly part of the HTTP/1.1 protocol), you will find that the internet will have occasionally transform either the headers or the entity-body or both, resulting in an uninterpretable and broken resource received at the client. Yes, this really happened, and oh my was it a pain to debug. In the end, despite being far better for the user, this feature was disabled for port 80 because it was not deployable. And yes, you are also right that people have attempted to use other protocols over port 80, and that proved problematic: The most interesting of which is probably WebSockets. As mentioned previously this essentially doesn't work. That leaves us with either using a new port (infeasible, failure rate still in high 10%s) or doing something else so as to be able to deploy. What is the something else would you suggest? -=R On Fri, Nov 15, 2013 at 8:02 AM, Nicolas Mailhot < nicolas.mailhot@laposte.net> wrote: > > Le Ven 15 novembre 2013 08:25, Roberto Peon a écrit : > > You are saying that we should use a port other than :443 for https > > traffic? > > ... why? > > What backdoor are we talking about? > > I'm saying that your whole problem with intermediaries in clear stems > directly from your attempts to push a new different protocol on a port > already used for something else (ie trying to enter through the back-door > like a juvenile delinquent because the guard on the main entry may object, > ensuring that he will consider you a suspicious character) > > -- > Nicolas Mailhot > >
Received on Friday, 15 November 2013 17:31:50 UTC