Re: Solution to the CGI message trap

    Yes, I was thinking of extending the namespace (ns) parameter to
    support this including only sending back the namespace ID because
    as you say, this is enough.

    It would also give explicit information about which extensions had
    been fulfilled in the case where the request contained a mix of
    mandatory and optional extensions.

I'm not sure whether that would be mixing up two different mechanisms.
I would use a single nonce to ensure that the communication path
is free of ignorant caches and CGI scripts; i.e., if the client
gets the correct nonce back in the response, then it's sure that
everyone is playing by whatever rules are defined for the nonce
Ack.

    Then I ran into thoughts about too much overhead of adding
    potentially several UUIDs to each request

If you want to know which of several extensions were fulfilled,
you could do this with a separate (and probably more compact)
ID space. I.e., use a set of integers 0..N in a request with N
extensions, and get back a subset of that set (or perhaps even
a binary encoding of a bitmap).  Since these extension-IDs don't
have to also serve as integrity checks, they don't have to be
very large.

    and not being able to see
    the result without parsing the whole message

Well, life is sometimes hard.  Buffering the response headers before
acting upon the response seems like a small price to pay (e.g.,
there's no guarantee that Content-Type will come before the last
header, so the client can't do much until it sees that, anyway).

    [102] would of course not work through 1.0 proxies. Hmm, now I
    don't know.

Exactly my point.  While sending and acking the nonce does add
some header bytes, it seems (at least, after a few minutes'
worth of thought) to "solve" the problem in the sense of getting
correct answers.  Then you can optimize; for example, maybe the
client doesn't need to send a nonce on subsequent requests if
the first one worked out.

But if you can't guarantee correctness, you can't optimize.

-Jeff

Received on Friday, 7 August 1998 17:48:05 UTC