Caching

2005-05-18

When a Jabber client logs into its server, it gets a lot of information -- mainly the user's "roster" (see RFC 3921) and service discovery information about the server and its associated services (see JEP-0030). Oftentimes, that information has not changed at all since the client last logged in. Wouldn't it be nice to get that data only if it has changed? As Joe Hildebrand pointed out to me a few months back, HTTP has such a mechanism, called eTags (some helpful pointers are here, see also this post by Sam Ruby). Well, given that JEP-0131 enables an XMPP entity to include any HTTP header in an XML stanza and thus inherit all the nice semantics defined in other specifications, by extension we can say that XMPP also supports eTags. Here's how it would work:

User requests roster with eTag SHIM header:

<iq type='get' id='roster1'>
 <query xmlns='jabber:iq:roster>
    <headers xmlns='http://jabber.org/protocol/shim'>
      <header name='eTag'>1993b6-e3-41d22f60</header>
    </headers>
 </query>
</iq>
    

If the roster has not changed, the server returns a 304 error:

<iq type='error' id='roster1'>
 <query xmlns='jabber:iq:roster>
    <headers xmlns='http://jabber.org/protocol/shim'>
      <header name='eTag'>1993b6-e3-41d22f60</header>
    </headers>
 </query>
  <error code='304' type='modify'>
    <not-modified xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq> 
    

JEP-0131 defines ways to determine if an entity supports SHIM and particular SHIM headers (which information would also be cached), so a client could know up front whether eTags are supported. We would need to add support for the error condition to RFC 3920, but we'll be working on rfc3920bis before long, so that's eminently doable. The bandwidth benefits could be significant, especially when someone like me (600+ roster items) logs in. ;-)


Peter Saint-Andre > Journal