Changes between Initial Version and Version 1 of Ticket #150, comment 15


Ignore:
Timestamp:
10/04/2013 01:02:27 PM (11 years ago)
Author:
nejucomo
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #150, comment 15

    initial v1  
    22> I agree with the approach in general. It's not clear to me that a standard HTTP proxy can handle the binary foolscap protocol: the first "hello" message is made to look HTTPish, but unless the proxy immediately jumps into a byte-relay mode after the HTTP response, the rest of the protocol will get confused. OTOH, if you got this to work with I2P's proxy, then I guess it's good enough.
    33
     4I wrote a long comment about how foolscap should follow websockets by using an ``Upgrade:`` header, then read negotiate.py where it's clearly commented that it does.
    45
    5 It's been quite a while since I looked at the foolscap negotiation protocol, but I believe these are true:
     6So the unknown seems to be: can "standard" ``HTTP`` proxies correctly proxy this upgraded protocol?  It seems the same issue should apply to websockets, unless specs or implementations have hard-coded special cases specific to websockets.
    67
    7 * The initial bytes are from client-to-server and look like an ``HTTP`` ``GET``.
    8 * A server responds, and the response may look like an ``HTTP`` ``302``, or it may look like something else which "hot swaps" the protocol into non-``HTTP``.
     8A quick skim of the first part of [http://www.infoq.com/articles/Web-Sockets-Proxy-Servers How HTML5 Web Sockets Interact With Proxy Servers] suggests that browsers using knowledge that a connection is for websockets will use the proxy ``CONNECT`` method with non-transparent (explicit) proxies.  So I would assume a general foolscap "web proxy" setting to have the same behavior and similar interoperability.
    99
    10 If both are true, I do not believe altering the ``GET`` to look like an ``HTTP`` proxy ``GET`` (by including a hostname) will work with ``HTTP`` proxies in general.  I believe [http://www.w3.org/Protocols/rfc2616/rfc2616.html RFC2616] is somewhat ambiguous with proxies, such that I don't have a strong expectation for how real-world proxies would handle the foolscap negotiation, nor how this patch would affect that.
     10This patch is different, and I have less confidence it will interoperate correctly with general ``HTTP`` proxies, although it may work specifically with an ``i2p`` specific proxy.
    1111
    12 To me, it seems like the foolscap negotiation should follow the websockets ``Upgrade: <something something>`` header and semantics, under the assumption that [http://tools.ietf.org/html/rfc6455 RFC6455] usefully anticipates similar interactions with proxies.  (Here's a [http://tools.ietf.org/html/rfc6455#page-5 quick example] of upgrading to websockets from ``HTTP``.)
    13 
    14 If foolscap negotiation does not already do this, then maybe there should be a new ticket proposing a protocol upgrade path that eventually results in something that has better interoperability with ``HTTP``, proxy servers being an excellent test case.  (I don't have time at the moment to determine if this is necessary, nor if the websockets protocol interoperates well in the first place...)
     12Therefore:
    1513
    1614>
    1715> I'd just be worried about labeling this option "httpProxy" if "i2p-proxy" would be a more accurate name.
    1816
    19 +1 because I'm not convinced it interacts with general proxies well.  Relying on the behavior of some implementations or custom protocols calls for a more specific name, IMO.
     17+1
     18
     19Relying on the behavior of some implementations or custom protocols calls for a more specific name, IMO.
     20
     21'''EDIT:''' Removed a lot of verbosity about rfc2616 and speculation about how foolscap negotiation should do what it already does.  ;-)