01-19-04 02:29 PM
Hi!
I am trying to develop an HTTP tunneling solution for a full-duplex
TCP/IP connection (i.e. unsolicited data can flow in either direction
---- solicited data is also supported). The idea is to come up with a
solution that has the best chance to make it past the firewalls. The
assumption that the HTTP port (80) is more than likely to be allowed
by the network administrators through their firewalls is the bedrock
upon which the entire edifice of SOAP is built, and I am trying to
leverage that. Unfortunately there do not appear to be any standards
on HTTP tunneling. The closest thing to a standard that I have seen
is an internet draft by Ari Luotonen ("Tunneling TCP based protocols
through Web proxy servers"). It is more than five years old but
somehow it was never elevated to the RFC status. Does anyone know the
reason why?
Luotonen's draft proposes extending the set of "methods" supported by
HTTP by introducing the "CONNECT" method. Interestingly, all that the
HTTP 1.1 specification (RFC 2616) mentions about the CONECT method is
the following:
This specification reserves the method name CONNECT for use with a
proxy that can dynamically switch to being a tunnel (e.g. SSL
tunneling [44]).
Since this proposal did not become an Internet Standard, I wonder if
relying on Luotonen's solution is risky. Any thoughts?
Fortunately our system runs the HTTPS protocol (port 443) and as such
there is no possibility of our full-duplex client/server connection
interfering with normal web server operation. Of course, there is a
chance that a user may, inadvertently, send requests using HTTP
(running on port 80) and not HTTPS (running on port 443). Such
requests need to be recognized and handled properly. By handled
properly I mean the server should serve back a page that provides the
correct URL to use.
In the absence of a standard for HTTP tunneling, I have come up with a
proposal and I would like to subject it to peer review and solicit
your feedback.
In formulating my proposal, I have been guided by the over-riding
consideration that it should work with any fully-compliant HTTP/1.1
application level gateway. I have gone through RFC-2616 and I have
identified some HTTP header fields and response codes that
"intermediaries" are NOT ALLOWED to block and/or alter. IMHO, a
solution woven around these header fields and response codes
represents the best chance for our client/server communication making
it past the firewalls.
Kindly note the use of the phrase "fully-compliant HTTP/1.1
application level gateway". The solution that I am proposing uses
some HTTP/1.1 features and will not work with HTTP/0.9 and HTTP/1.0
application level gateways. According to RFC2616, "a proxy/gateway
MUST NOT send a message with a version indicator which is greater than
its actual version. If a higher version request is received, the
proxy/gateway MUST either downgrade the request version, or respond
with an error, or switch to tunnel behavior" (RFC2616, Section 3.1).
This may, on the surface, seem to be a limitation, but requiring
application level gateways to comply with HTTP/1.1 does not seem
overly restrictive to me. Furthermore, I think that if I stick to a
well known and well implemented industry standard, I am in safe
territory.
This proposal leverages the fact that HTTP supports the Pragma general
header field. This field can be present in both request and response
messages and its contents are left to the implementation. More
importantly HTTP/1.1 compliant proxies and gateways are required to
let the Pragma directives pass through (RFC2616, Section 14.32).
Additionally, this proposal leverages the fact that proxies cannot
block response messages with status codes 100 and 101 (RFC2616,
Section 10.1). Status code 100 (Continue) looks extremely promising.
As per RFC2616, Section 10.1.1, "This interim response is used to
inform the client that the initial part of the request has been
received and has not yet been rejected by the server".
As per Section 8.2.3, "An origin server that sends a 100 (Continue)
response MUST ultimately send a final status code, once the request
body is received and processed, unless it terminates the transport
connection prematurely". Again as per Section 10.1.1, "The server
MUST send a final response after the request has been completed".
These interim response messages provide a convenient vehicle for the
server to keep "pushing" unsolicited data to the client.
Unfortunately this data cannot be in the message body (as per RFC2616,
Sections 4.3 and 4.4), but it can be carried in the Pragma header
fields. Of course, any binary data would have to be first encoded as
text before it is stuck in the header. A response can have multiple
Pragma fields since multiple message-header fields with the same
field-name are supported (RFC2616, Section 4.2).
The remainder of this post is devoted to describing my proposal.
The client makes an HTTP request to the server. The fields in the
request message are listed below. The ordering of the fields is as
per the "good-practices" discussed in Section 4.2.
1. Request Line
• Mandatory as per RFC2616, Section 5
2. Pragma
• Since there are no restrictions from HTTP/1.1 on the contents of
this field, this field will contain the session ID
• There may also be a need to fill in some distinguishing feature of
the full-duplex client/server messages so that the server can
unambiguously distinguish between legitimate full-duplex client/server
messages and misdirected HTTP maintenance requests
3. Host
• As per RFC2616, Section 14.23, "A client MUST include a Host header
field in all HTTP/1.1 request messages"
• This field may have an empty value
4. Expect
• This field will contain the value "100-continue". Although as per
RFC2616, Section 8.2.3, this header field may not be needed, it may be
better to include this field to improve the chances of getting past
the firewall since "If a proxy receives a request that includes an
Expect request-header field with the '100-continue' expectation, and
the proxy either knows that the next-hop server complies with HTTP/1.1
or higher, or does not know the HTTP version of the next-hop server,
it MUST forward the request, including the Expect header field"
(RFC2616, Section 8.2.3. Also see Section 14.20)
Upon receiving this request, the server issues the first "interim"
response message. The fields in this message are listed below. The
ordering of the fields is as per the "good-practices" discussed in
RFC2616, Section 4.2.
1. Response Line
• Mandatory as per RFC2616, Section 6. The value of the Status-Code
attribute shall be 100 and the value of the Reason-Phrase attribute
shall be "Continue"
2. Pragma (n>1 instances of this header field)
• Since there are no restrictions from HTTP/1.1 on the contents of the
Pragma fields, these fields may be used to provide some proprietary
information.
3. Content-length
The server may keep pushing data asynchronously to the client. The
structure of these messages is identical to the first "interim"
response message described above.
Termination of the communication session can be initiated from either
the client or from the server. In the former case the server will
detect the termination of the connection upon the expiration of a
keep-alive timer or upon attempting to asynchronously push data to the
client, and it will perform the pertinent clean up activities.
In the latter case, the server will send its final response message to
the client after completing the clean up activities mentioned above.
The final response message will have Status-code attribute set to 200
(OK), causing the underlying transport connection to be closed.
I would deeply deeply appreciate if someone takes the time to study
this proposal and provide feedback. Kindly keep in mind that it is my
intention to come up with a solution that application level gateways
will allow through. If there is an alternate solution that might work
better, kindly feel free to share it with me.
Regards,
KP Bhat
kpbhat @ sta . Samsung . com
[ Post a follow-up to this message ]
| 
