Mostly nit picking...
At 10:45 9/11/2001 +0100, andrew wrote:
The proxylet engine interacts with proxylets via interfaces from the
org.ietf.opes.proxylet package. The protocol-specific proxylet
extensions are found within the a sub package from
org.ietf.opes.proxylet. For example, HTTP proxylets use the package
org.ietf.opes.proxylet.http.
I would have assumed that it should be IANA rather than IETF in that hierarchy.
protocol message types. For example, HTTPProxylet
will have modGetRequest and a modGetResponse methods dealing with the
adaption of a HTTP GET requests and its subsequent response message.
I'm not a Java programmer (so might be missing something), but wouldn't it
make sense to make these something like:
<mumble>.http.get.modRequest
<mumble>.http.get.modResponse
6.1 Cookie
Cookie represents the access interface for HTTP-like cookies. A
cookie is a name value pair that is associated with a request, and
assigned to the user as part of the response.
Cookies are associated with responses too. s/user/user agent/
Cookie.getValue() with no parameters certainly seems to assume a single
cookie in the request/response. There could be many.
I suspect Cookie.getName() should return a list of names.
Same problem in Cookie.setValue() - assumes there's only one cookie's value
being set.
I see similar problems in 6.13 (just skimming the document after 6.1, sorry).
(Are you assuming cookie header concatenation in the above?)
[OK, I'm just re-reading parts of this... is 6.1 an *internal* cookie? It
seems my comments above are addressed later in 6.1[45], which suggests the
wording in 6.1 might need improvement to identify the scope.)
In 6.15, HTTPProxyletRequest.getHeader() string concatenates a header. The
corresponding .setHeader() I assume creates a single concatenated header in
the new HTTP header... While there's an issue of "but 2616 says..." here, I
think this is somewhere it might be better to err on the side of caution
and allow for non-concatenated headers. Of course, there's an ordering
issue to be considered here.