justin-keyword-jabber.093179 at affinix.com
Tue Feb 24 23:05:08 UTC 2004
On Tuesday 24 February 2004 2:22 pm, Barry Latimer wrote:
> If all that is required is a HTTP tunnel that allows XMPP to be sent over
> HTTP then couldn't a more generic tunnelling protocol be looked at?
JEP-25 is the first I've ever seen of such a spec actually documented, and I'm
not aware of any others.
One of the first hits on google for http tunnelling is 'GNU Http Tunnel',
though I have no idea what protocol it uses.
> 1) JEP-25 examples are incorrect (minor problem) as they say all request's
> from the client should be sent using the Content Type of
> "application/x-www-form-urlencoded" then the examples are not encoded (from
> previous experience this tends to means that you will get implementations
> that do not URL encode the data before sending it).
> 2) JEP-25 incorrectly uses a content type of "text/xml" for the server's
> response when the response sent back to the client is not a valid XML
> document fragment, in fact it is a "text/plain" document that the client
> needs to parse before it can use the xml fragment contained within.
Well, the content type is pretty much ignored. Consider the text in Section
3, third paragraph: "Both the request and response bodies are UTF-8 encoded
text, even if an HTTP header to the contrary exists."
Of course, this sounds quite silly, and it might be worth updating the
document, though I'd vote for application/octet-stream instead of text/plain.
> 3) JEP-25 forces both the server and client to use UTF-8 encoding
> regardless of what the HTTP headers specify. Which means that a developer
> is can be unable to use HTTP libraries that will automatically
> encode/decode the HTTP data. Also what happens when the data is sent
> through a transparent proxy that decides to use a different form of
> encoding ??
I think the rationale for this is that XMPP itself is in UTF-8 format.
However, both the HTTP and XMPP layers cannot be UTF-8, otherwise you'd end
up doubly encoding, which does not happen in existing implementations. I've
always interpretted this bit about UTF-8 in JEP-25 as a 'hint'. But really,
what you end up doing is considering the HTTP exchange as raw binary data,
and then the UTF-8 format is processed in your XMPP engine.
More information about the Standards