Ahead of this week's workshop we wanted to post a list of all the
bugs/inconsistencies that we have found in the current iCAP draft and
also some suggestions on how to improve iCAP:
Bugs/Inconsistencies in the current iCAP Draft
==============================================
- "Encapsulated" header syntax ("," or blank as delimiter?)
The definition of the "Encapsulated" header shows a single blank as
delimiter between the elements of the header value. The examples,
however, show a comma.
- Expected Encapsulated Sections
The chart given in the draft lists the encapsulated sections that
"should" be used in the two different modes. The draft is not clear
about the circumstances under which certain sections may be omitted from
the message. For instance, in request modification mode, the original
request may or may not contain a request body, but the iCAP draft says
that in request modification mode iCAP requests should always include a
request body.
The draft is also not clear about whether it is legal to intentionally
omit a certain section of an original HTTP message in an iCAP
transaction. For instance, some iCAP services may not need to see
request bodies even when they are present in the original request. Does
the iCAP draft allow the iCAP client to intentionally omit the request
body from the request in such cases? The same is true for omitting other
sections of HTTP message, e.g. response bodies.
If iCAP services require to see a certain section of the HTTP message,
but this section is not present in a given HTTP message (e.g. a HTTP
response without body), the iCAP client should encapsulate the required
section with no content (by encapsulating a "0" chunk only). This should
be made clear in the draft.
- Encoding of encapsulated HTTP headers (chunked or unchunked?)
At one point the draft says that for iCAP message chunked encoding a la
HTTP/1.1 is to be used. In the examples, however, only the encapsulated
HTTP bodies are chunk encoded.
- Wrong chunk sizes in examples
There are several incorrect chunk sizes in the iCAP examples.
- Handling of iCAP server errors
The draft mandates to return all iCAP error responses other than 200 and
204 to the user agent. What that draft probably means is that the iCAP
client should return any encapsulated HTTP error response to the use
agent. In case of iCAP error responses the iCAP client should probably
rather return the original HTTP response to the user agent. (This may
require refetching the HTTP response because the iCAP client is not
required to buffer the response prior to sending it to an iCAP server)
- iCAP error response body
The draft says nothing about the format of the iCAP message
body if an iCAP error is returned to the iCAP client (e.g. 404 iCAP
Service Not Found).
- "Connection: close" header
The examples in the draft use the "Connection: close" header from
HTTP/1.1. The draft, however, does not explicitly mention that this
header may be used in iCAP responses.
Suggestions for iCAP Improvements
=================================
- Chunked encoding for the entire iCAP message body
The implementation of iCAP servers can be facilitated by chunk encoding
the entire iCAP body (one goal of the iCAP design was to allow for easy
iCAP server implementations).
- iCAP server cannot always determine length of header section from byte
offset information
In request modification mode, iCAP requests may encapsulate an HTTP
request header section only. For such iCAP requests, iCAP servers cannot
determine the length of the encapsulated header section by looking at
the byte offset information in the "Encapsulated" header of the iCAP
request because the header contains only one byte offset: "Encapsulated:
req-hdr=0". A possible fix for this problem would be to add a "no-body"
section to the "Encapsulated" header in such cases.
- Connection-sharing
Currently, TCP connections between the iCAP client and iCAP server
cannot be shared by multiple concurrent iCAP transactions. Supporting
such a shared connection architecture could improve the performance of
iCAP transactions. It would require introducing unique iCAP message
IDs/sequencing numbers in order to order and assign incoming packets to
different iCAP transactions. Another alternative would also be to run
iCAP over BEEP which already has support for connection sharing.
-iCAP implementation notes
The draft should point out to iCAP client implementors that for
performance reasons iCAP client transactions absolutely require an
asynchronous read/write communication with iCAP servers. This may not be
obvious to iCAP implementors since it is not necessary in HTTP
implementations.
For the same reason, the draft should also point out to iCAP server and
iCAP service implementors that these should process and return incoming
iCAP messages as they receive them - chunk by chunk - and not buffer the
whole iCAP request whenever this is possible (some iCAP service must
see the entire HTTP message before they can return an iCAP response,
e.g. content filtering services).