The
identification of resources in the Web via URIs [add ref] may not be
sufficient to uniquely resolve a document as other factors might come into
play like HTTP content negotiation according to pre-defined user
characteristics. This issue is particularly important for conformance
testing, conformance claims and reporting languages like the Evaluation
and Repair Language (EARL, add ref) when they address Web resources. This
document describes a representation of HTTP concepts in RDF that will
serve to the purpose mentioned earlier, as it can allow the identification
of resources served via the HTTP protocol. The proposed vocabulary also
includes some extensions to HTTP outside the standard RFCs.
[Note] Shall be mention HTTPS here?
This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of
current W3C
publications and the latest revision of this technical report can be found
in the W3C technical reports
index at http://www.w3.org/TR/.
More things to be added later ...
To be defined at a later stage
...
This note presents an RDF representation of the
HTTP headers that can support the unique identification of Web resources
when the sole use of an URI [add ref] may not suffice due to common
content negotiation techniques used by most browsers nowadays. It also
will help to identify complex Web resources like form responses, which
need, for example, information on the POST request used and the sent
parameters. This document is not intended to be a clarification of the
different concepts of the HTTP specification [RFC2616].
[Note] Use cases
discussion? E.g., EARL, conformance claims, Web Services in the Semantic
Web, ...
In this document we refer to
version 1.1 of HTTP. Section 3 refers to common extensions used in the
Web, and how they can be incorporated into the vocabulary. As defined in
[RFC2616], The Hypertext Transfer
Protocol (HTTP) is an application-level protocol for distributed,
collaborative, hypermedia information systems. HTTP is a
request/response protocol, and therefore, the basic classes represent this
structure message format [RFC822]:
- Request message.
- Response message.
The Request class represents an HTTP
request. There are eight subclasses derived from the Request
class, one for each request type defined in [RFC2616]:
OptionsRequest, representing an HTTP Options
request,GetRequest, representing an HTTP Get request,HeadRequest, representing an HTTP Head request,PostRequest, representing an HTTP Post request,PutRequest, representing an HTTP Put request,DeleteRequest, representing an HTTP Delete
request,TraceRequest, representing an HTTP Trace
request,ConnectRequest, representing an HTTP Connect
request.
The following properties may appear in nodes
of type Request:
serverHost representing the host server to connect
to,serverPort representing the server port to connect
to,absPath representing the absolute path of the URL for
the resource to request,version representing the version of HTTP.
The Response class represents an
HTTP response as defined in [RFC2616].
The
following properties may appear in nodes of type
Response:
responseCode representing the response code sent by
the server.
The header property represents an
HTTP header. There is a property derived from the header property for
every header defined in [RFC2616]. The
following properties may appear in nodes of type
Request:
accept representing an Accept header,acceptCharset representing an Accept-Charset
header,acceptEncoding representing an Accept-Encoding
header,acceptLanguage representing an Accept-Language
header,authorization representing an Authorization
header,expect representing an Expect header,from representing a From header,host representing a Host header,ifMatch representing an If-Match header,ifModifiedSince representing an If-Modified-Since
header,ifNoneMatch representing an If-None-Match
header,ifRange representing an If-Range header,ifUnmodifiedSince representing an If-Unmodified-Since
header,maxForwards representing a Max-Forwards header,proxyAuthorization representing a Proxy-Authorization
header,range representing a Range header,referer representing a Referer header,te representing a TE header,userAgent representing a User-Agent header.
The following properties may appear in nodes of type
Response:
acceptRanges representing a Accept-Ranges
header,age representing an Age header,etag representing an ETag header,location representing a Location header,proxyAuthenticate representing a Proxy-Authenticate
header,retryAfter representing a Retry-After header,server representing a Server header,vary representing a Vary header,wwwAuthenticate representing a WWW-Authenticate
header.
The following properties may appear in nodes of type
Request or Response:
allow representing an Allow header,cacheControl representing a Cache-Control
header,connection representing a Connection header,contentEncoding representing a Content-Encoding
header,contentLanguage representing a Content-Language
header,contentLength representing a Content-Length
header,contentLocation representing a Content-Location
header,contentMD5 representing a Content-MD5 header,contentRange representing a Content-Range
header,contentType representing a Content-Type header,date representing a Date header,expires representing an Expires header,lastModified representing a Last-Modified
header,pragma representing a Pragma header,trailer representing a Trailer header,transferEncoding representing a Transfer-Encoding
header,upgrade representing an Upgrade header,via representing a Via header,warning representing a Warning header.
The body property represents an HTTP
entity body. It can appear in nodes of both type Request or
Response. HTTP bodies are series of bytes, thus we need to
translate that to a string of text with a given encoding to make it
representable in RDF. The body is then represented by an anonymous
Resource with two properties:
bodyContent representing bytes in the entity
body,bodyEncoding representing the encoding used to encode
the bytes in the entity body.
...
There are quite a lot of headers widely used in HTTP,
which are not defined in the HTTP/1.1 specification itself. The following
extension properties may appear in nodes of type
Request:
acceptFeatures representing an Accept-Features header
(defined in [RFC2295])cookie representing an Cookie header (defined in [Cookie] and [RFC2965])cookie2 representing an Cookie2 header (defined in
[RFC2965])negotiate representing an Negotiate header (defined
in [RFC2295])
The following extension properties may appear in nodes of type
Response:
alternates representing an Alternates header (defined
in [RFC2295])contentDisposition representing a Content-Disposition
header (defined in [RFC2183])p3p representing a P3P header (defined in [P3P])setCookie representing a Set-Cookie header (defined
in [Cookie])setCookie2 representing a Set-Cookie2 header (defined
in [RFC2965])tcn representing a TCN header (defined in [RFC2295])variantVary representing a Variant-Vary header
(defined in [RFC2295])
For headers not defined in HTTP/1.1 or any of the
previous extensions, you can use the additionalHeader
property. The object of this property is of type
Field.
The Field class
represents a field defined in [RFC822], and
should be in a different namespace. It can have the following
properties:
fieldName representing a field name defined in [RFC822],fieldBody representing a field body defined in [RFC822].
<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:earl="http://www.w3.org/WAI/ER/EARL/nmg-strawman#"
xmlns:http="http://www.w3.org/1999/xx/http#"
xmlns:rfc822="http://www.example.org/rfc822#">
<earl:WebContent rdf:about="http://www.example.org/">
<earl:httpRequest>
<http:GetRequest>
<http:host>www.example.org</http:host>
<http:port>80</http:port>
<http:absPath>/</http:absPath>
<http:version>1.1</http:version>
<http:accept>text/html;q=1.0, */*;q=0.01</http:accept>
<http:acceptLanguage>de-DE;q=1.0, de;q=0.75, en-GB;q=0.5, en;q=0.25, *;q=0.01</http:acceptLanguage>
</http:GetRequest>
</earl:httpRequest>
<earl:httpResponse>
<http:Response>
<http:contentType>text/html;charset=utf-8</http:contentType>
<http:vary>negotiate, accept, accept-language</http:vary>
<http:additionalHeader>
<rfc822:Field>
<rfc822:fieldName>x-foo</rfc822:fieldName>
<rfc822:fieldBody>bar</rfc822:fieldBody>
</rfc822:Field>
</http:additionalHeader>
<http:body rdf:parseType="Resource">
<http:bodyContent><![CDATA[aksgbq3833o3gbo4zgblakc8t9ut2]]></http:bodyContent>
<http:bodyEncoding>Base64</http:bodyEncoding>
</http:body>
</http:Response>
</earl:httpResponse>
</earl:WebContent>
</rdf:RDF>
- [Cookie]
- Persistent
client state HTTP cookies – Netscape Preliminary
Specification
- [P3P]
- "The Platform for Privacy
Preferences 1.0 (P3P1.0) Specification" – Lorrie Cranor, Marc
Langheinrich, Massimo Marchiori, Martin Presler-Marshall, Joseph
Reagle, W3C Recommendation, 16 April 2002.
- [RDF]
- "Resource Description
Framework (RDF): Concepts and Abstract Syntax" – Graham Klyne,
Jeremy J. Carroll, W3C Recommendation, 10 February 2004.
- [RFC822]
- "Standard for ARPA
Internet Text Messages" – David H. Crocker, August 13, 1982.
- [RFC2183]
- "Communicating
Presentation Information in Internet Messages: The Content-Disposition
Header Field" – R. Troost, S. Dorner, K. Moore, August 1997.
- [RFC2295]
- "Transparent Content
Negotiation in HTTP" – K. Holtman, A. Mutz, March 1998.
- [RFC2616]
- "Hypertext Transfer
Protocol -- HTTP/1.1" – R. Fielding, J. Gettys, J. Mogul, H.
Frystyk Nielsen, L. Masinter, P. Leach and T. Berners-Lee, June
1999.
- [RFC2965]
- "HTTP State
Management Mechanism" – D. Kristol, L. Montulli, October
2000.