This section shows an example of an OPTIONS method call. OPTIONS is described in §9.2 in RFC 2616.

This section shows an example of a GET method call. GET is described in §9.3 in RFC 2616.

Note: The XMPP/HTTP bridge at the server only transmits headers literally as they are reported, as if it was normal HTTP over TCP that was used. In the HTTP over XMPP case, connections are not handled in the same way, and so the "Connection: Close" header has no meaning in this case. For more information about connection handling in the HTTP over XMPP case, see the section on Connection Handling.

This section shows an example of a HEAD method call. HEAD is described in §9.4 in RFC 2616.

This section shows an example of a POST method call. POST is described in §9.5 in RFC 2616.

Note: If using xml encoding of data, care has to be taken to avoid including the version and encoding information (<?xml version="1.0"?>) at the top of the document, otherwise the resulting XML will be invalid. Care has also to be taken to make sure that the generated XML is not invalid XMPP, even though it might be valid XML. This could happen for instance, if the XML contains illegal elements from the jabber:client namespace. If in doubt, use another encoding mechanism.

This section shows an example of a PUT method call. PUT is described in §9.6 in RFC 2616.

This section shows an example of a DELETE method call. DELETE is described in §9.7 in RFC 2616.

This section shows an example of a TRACE method call. TRACE is described in §9.8 in RFC 2616.

Note: The Trace command returns the request it received from the client by the server. Here, however, it is assumed that the request is made over HTTP/TCP, not HTTP/XMPP. Therefore, in this example, the XMPP layer has transformed the HTTP/XMPP request into an HTTP/TCP-looking request, which is returned as the response to the TRACE Method call. RFC 2616 is silent to the actual format of the TRACE response (MIME TYPE message/http), and TRACE is only used (if not disabled for security reasons) for debugging connections and routing via proxies. Therefore, a response returning the original XMPP request should also be accepted by the caller.

This section shows an example of a PATCH method call. PATCH is described in RFC 5789.

Text responses is a simple way to return text responses (i.e. any MIME Type starting with text/). Since the text is embedded into XML, the characters <, > and & need to be escaped to &lt;, &gt; and &amp; respectively.

The following example shows how a TURTLE response, which is text-based, is returned using the text encoding:

XML is a convenient way to return XML embedded in the XMPP response. This can be suitable for MIME Types of the form .*/(.*[+])?xml (using regular expression to match them), like text/xml, application/soap+xml or application/sparql-results+xml. Care has to be taken however, since not all XML constructs can be embedded as content to an XML element without invalidating it, like the xml version and encoding declaration (<?xml version="1.0"?> as an example). Care has also to be taken to make sure that the generated XML is not invalid XMPP, even though it might be valid XML. This could happen for instance, if the XML contains illegal elements from the jabber:client namespace.

If unsure how to handle XML responses using the xml encoding type, you can equally well use the text type, but encode the XML escape characters <, > and &, or use another encoding, like base64.

The advantage of xml instead of text or base64 encodings is when used in conjunction with EXI compression. EXI compression has the ability to compress XML efficiently. Text will not be compressed, unless response exists in internal string tables. Base-64 encoded data will be compressed so that the 33% size gain induced by the encoding is recaptured.

Base-64 encoding is a simple way to encode content that is easily embedded into XML. Apart from the advantage of being easy to encode, it has the disadvantage to increase the size of the content by 33%, since it requires 4 bytes to encode 3 bytes of data. Care has to be taken not to send too large items using this encoding.

Note: The actual size of the content being sent does not necessarily need to increase if this encoding method is used. If EXI compression is used at the same time, and it uses schema-aware compression, it will actually understand that the character set used to encode the data only uses 6 bits of information per character, and thus compresses the data back to its original size.

The following example shows an image is returned using the base64 encoding:

In HTTP, Chunked Transfer Encoding is used when the sender does not know the size of the content being sent, and to avoid having its buffers overflow, sends the content in chunks with a definite size.

A similar method exists in the HTTP over XMPP transport: The chunkedBase64 allows the sender to transmit the content in chunks. Every chunk is base-64 encoded. The stream of chunks are identified by a streamId parameter, since chunks from different responses may be transmitted at the same time.

Another difference between normal chunked transport, and the chunkedBase64 encoding, is that the size of chunks does not have to be predetermined. Chunks are naturally delimited and embedded in the XML stanza. The last chunk in a response must have the last attribute set to true.

Note: Chunked encoding assumes the content to be finite. If content is infinite (i.e. for instance live streaming), the ibb or jingle transfer encodings must be used instead. If the sender is unsure if the content is finite or infinite, ibb or jingle must be used.

Note 2: If the web server sends chunked data to the client it uses the HTTP header Transfer-Encoding: chunked, and then sends the data in chunks but with chunk sizes inserted so the receiving end can decode the incoming data. Note that this data will be included in the data sent in the XMPP chunks defined by this document. In this case, data will be chunked twice: First by the web server, and then by the HTTP over XMPP transport layer. When received by the client, it is first reassembled by the HTTP over XMPP layer on the client, and then by the HTTP client who will read the original chunk size elements inserted into the content. More information about HTTP chunking, can be found in RDF2616 §3.6.1.

Note 3: In order to work over XMPP servers that do not maintain message order, a nr attribute is available on the chunk element. The first chunk reports a nr of zero. Each succcessive chunk reports a nr that is incremented by one. In this way, the receiver can make sure to order incoming chunks in the correct order.

Often content being sent can be represented by a file, virtual or real, especially if the content actually represents a file and is not dynamically generated. In these instances, instead of embedding the contents in the response, since content can be potentially huge, a File Stream Initiation is returned instead, as defined in XEP 0137: Publishing Stream Initiation Requests. This is done using the sipub element.

Some web servers provide streaming content, i.e. content where packets are sent according to a timely fashion. Examples are video and audio streams like HLS (HTTP Live Streams), SHOUTcast, ICEcast, Motion JPeg, etc. In all these examples, content is infinite, and cannot be sent "all as quickly as possible". Instead, content is sent according to some kind of bitrate or frame rate for example.

Such content must use the ibb transfer mechanism, if used (or the jingle transfer machanism). The ibb transfer mechanism uses In-Band Bytestreams to transfer data from the server to the client. It starts by sending an a ibb element containing a sid attribute identifying the stream. Then the server sends an ibb:open IQ-stanza to the client according to XEP-0047. The client can choose to reject, negotiate or acceopt the request whereby the transfer is begun. When the client is satisified and wants to close the stream, it does so, also according to XEP-0047. The sid value returned in the HTTP response is the same sid value that is later used by the IBB messages that follow. In this way, the client can relate the HTTP request and response, with the corresponding data transferred separately.

For demanding multi-media streams alternative methods to transport streaming rather than embedded into the XMPP stream may be required. Even though the ibb method may be sufficient to stream a low-resolution web cam in the home, or listen to a microphone or a radio station, it is probably badly suited for high-resolution video streams with multiple video angles and audio channels. If such content is accessed and streamed, the server can negotiate a different way to stream the content using XEP 0166: Jingle.

Note: Example taken from XEP 166: Jingle.

Note2: Using Jingle in this way makes it possible for an intelligent server to return multiple streams the client can choose from, something that is not done in normal HTTP over TCP. The first candidate should however correspond to the same stream that would have been returned if the request had been made using normal HTTP over TCP.

HTTP began as a protocol for presenting text in browsers. So, browsers is a natural place to start to list use cases for this extensions. In general, content is identified using URL's, and in the browser a user enters the URL into Address Field of the browser, and the corresponding content is displayed in the display area. The content itself will probably contain links to other content, each such item identified by an absolute or relative URL.

Many applications use a Service Oriented Architecture (SOA) and use web services to communicate between clients and servers. These web services are mostly HTTP over TCP based, even though there are bindings which are not based on this. The most common APIs today (REST) are however all based on HTTP over TCP. Being HTTP over TCP requires the web server hosting the web services either to be public or directly accessible by the client. But as the services move closer to end users (for instance a Thermostat publishing a REST API for control in your home), problems arise when you try to access the web service outside of private network in which the API is available. As explained previously, the use of HTTP over XMPP solves this.

The Semantic Web was originally developed as a way to link data between servers on the Web, and understand it. However, with the advents of technologies such as SPARQL, the Semantic Web has become a way to unify API's into a universal form of distributed API to all types of data possible. It also allows for a standardized way to perform grid computing, in the sense that queries can be federated and executed in a distributed fashion ("in the grid").

For these reasons, and others, semantic web technologies have been moving closer to Internet of Things, and also into the private spheres of its end users. Since the semantic web technologies are based on HTTP, they also suffer from the shortcomings of HTTP over TCP, when it comes to firewalls and user authentication and authorization. Allowing HTTP transport over XMPP greatly improves the reach of semantic technologies beyond "The Internet" while at the same time improving security and controllability of the information.

As the semantic web moves closer to Internet of Things and the world of XMPP, it can benefit from work done with relation to the Internet of Things, such as &xep0324;, which would give automatic control of who (or what) can communicate with whom (or what).

There are many types of streams and streaming protocols. Several of these are based on HTTP or variants simulating HTTP. Examples of such HTTP-based or pseudo-HTTP based streaming protocols can include HLS HLS: HTTP Live Streaming <http://en.wikipedia.org/wiki/HTTP_Live_Streaming> used for multi-media streaming, SHOUTcast SHOUTcast <http://en.wikipedia.org/wiki/SHOUTcast> used for internet radio and Motion JPeg Motion JPeg <http://en.wikipedia.org/wiki/Motion_JPEG> common format for web cameras.

Common for all streaming data, is that they are indefinite, but at the same time rate-limited depending on quality, etc. Because of this, the web server is required to use the ibb encoding or the jingle encoding to transport the content to the client.

A public server should accept requests from anybody (reachable from the current JID). All friendship requests should be automatically accepted.

To avoid bloating the roster, friendship requests could be automatically unsubscribed once the HTTP session has ended.

All new friendship are shown (or queued) to an administrator for manual acceptance or rejection. Once accepted, the client can access the corresponding content. During the wait (which can be substantial), the client should display a message that the friendship request is sent and response is pending.

Automatic unsubscription of friendships should only be done on a much longer inactivity timeframe than the normal session timeout interval.

All new friendship requests are automatically rejected. Only already accepted friendships are allowed to make HTTP requests to the server.

All new friendship requests are delegated to a trusted third party, according to XEP 0324: Internet of Things - Provisioning. Friendship acceptance or rejection is then performed according to the response from the provisioning server(s).

Automatic friendship unsubscription can be made to avoid bloating the roster. However, the time interval for unsubscribing inactive users should be longer than the normal session timeout period, to avoid spamming any provisioning servers each time a client requests friendship.