W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > May 2007

Representing HTTP Requests Responses and Headers in moki

From: Jo Rabin <jrabin@mtld.mobi>
Date: Thu, 24 May 2007 09:44:35 +0100
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B4335F43@mtldsvr01.DotMobi.local>
To: <public-mobileok-checker@w3.org>

Following on from yesterday's post [1] here are some further thoughts
and questions as to how we represent HTTP headers in XML.

1. The moki prototype [2] document example models a retrieval via HTTP
as:

<retrieval>
	<retrievedURI>...</retrievedURI>
	<HTTPRequest/>
	<HTTPResponse/>
	<!-- and then a request/response pair for every redirection -->
	...
</retrieval>

Q1: Is there any benefit to enclosing each request response pair in an
element to bind them more closely together?

Proposed Answer: Probably not as it adds no information.

2. At present the proposal for modelling each header follows the style
of HTTP-in-RDF - i.e. it assumes that the structure of HTTP headers is: 

message-header  = field-name ":" [field-value]
field-value     = [header-element] *( "," [header-element] )
header-element  = element-name [ "=" [element-value ] ] *( ";" [param] )
param           = param-name [ "=" [param-value] ]
param-value     = (token | quoted-string)

i.e. that the header value field is composed of a sequence of "header
elements".

As noted in [1], this is actually not an accurate representation. It
does no harm, especially, as long as you remember not to parse e.g.
dates for the element separator, a comma. So for things like dates you
end up with:

<header name="date">
	<element name="2007-04-20T11:30:30Z"/>
</header>

And as long as you know that the value of the date is to be found as the
name attribute of an element child, that's ok. But it would probably be
clearer if instead of doing this we recognised that some headers are not
parsed in that way and instead we said:

<header name="date">
	<value>Tue, 15 Nov 1994 08:12:31 GMT</value>
</header>

Or

<header name="date">Tue, 15 Nov 1994 08:12:31 GMT</header>

Or

<header name="date" value="Tue, 15 Nov 1994 08:12:31 GMT" />

This would have the effect that the XSLT would need different ways of
accessing header data. Assuming you knew which header you were going for
this would not be a problem. If you wanted to iterate over all the
headers it would make the code a bit more complicated. On the up-side it
is a more simple direct representation, more directly accessible when
you need to value. On the down-side it means that if you don't know the
structure of a particular header you need to test for the presence of a
value attribute before accessing the data.

Q2: Which does the team think is the best approach?

Proposed answer: use the value= representation because then the
representation of unstructured values of headers, elements and
parameters is the same, it's the most compact way of doing it and it
adds to readability.

e.g. 

<header name="date" value="Tue, 15 Nov 1994 08:12:31 GMT" />

<header name="cache-control">
	<element name="no-store"/>
	<element name="no-cache"/>
	<element name="must-revalidate"/>
	<element name="post-check" value="0">
	<element name="pre-check" value="0">
</header>

<header name="accept">
	<element name="application/xhtml+xml"/>
	<element name="image/gif"/>
	<element name="image/jpeg"/>
	<element name="text/css"/>
	<element name="text/html">
		<parameter name="q" value="0.1" />
	</element>
	<element name="application/vnd.wap.xhtml+xml">
		<parameter name="level" value="1" />
		<parameter name="q" value="0.1" />
	</element>
</header>

3. Do we want to parse non RFC 2616 headers?

The only one I can think of (aside from authentication which is
referenced from RFC 2616) is cookies. But since we merely test for the
presence of cookies and do not analyse them, is it worth the bother?

Q3: Parse cookies or anything else?

Proposed Answer: No. Render their values as value = "..."

Jo

[1]
http://lists.w3.org/Archives/Public/public-mobileok-checker/2007May/0102
.html

[2]
http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Apr/att-
0047/moki-example-20070419.xml
Received on Thursday, 24 May 2007 08:44:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:13:03 GMT