[Top] [All Lists]

Re: A Java based proxylet API

2001-09-12 12:49:56

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

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:

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.

<Prev in Thread] Current Thread [Next in Thread>