>> - We have two strings that can be passed by a kxr_redirect:
>> - a "login" token which will be passed to the dest server in the login
>> phase and then cleared
>> - an "open" opaque info which will be passed to the dest server in the
>> open phase. This is not cleared, but can be overwritten by a subsequent
> I interpreted the behavior in the same way, but some questions remain:
Please see my earlier mail file. The end result will likely be what was
intended. The description here however can cause unintended results should
the redirector *not* supply a token. So, while the above would likely work
it would only work *most* of the time.
> Is there a destinction in the kxr_open request between opaque data coming
> from a redirect and opaque data to steer the open (as found in section
> 3.12.1 of the spec)?
> Is the "redirect opaque data" appended to the filename with a "?" in
> between or do we need an additional "&" as written in the spec?
Since the redirector and the client can both supply opaque data. and if it
is truly opaque, there is no distinction. Redirector and client supplied
data are cummalative. As per the spec, the data should always be of the form
'&var=value". Hence, it is complete valid to catenated two pieces of opaque
data together in any order. They will always start with an ampersand. So,
you should not need an additional ampersand. Now, that said, we recognize
the the first variable after the question mark need not have an ampersand to
be distinguishable. I think that even the cgi spec admits to that. However,
technically, it should have an ampersand as that is what the protocol spec
says it should have. Now, opaque data should be properly formed (i.e., it
should have an ampersand at the front). By definition, one should not
inspect or modify opaque data in any way. So, adding an ampersand would
violate that rule (and should not be necessary if the opaque data is
corerctly constructed). Obviously, all bets are off is someone violated the
In short, there is no need to write in an additional ampersand in the spec.
> Must the "redirect opaque data" be ASCII or can it be binary too?
The spec only alludes to the fact that no data in the path includiing the
appended opaque data may contain binary information. Only ASCII text is
allowed. I should make that obvious in the spec.
>> For those who are going to be in Mumbai, Patrick and Tigran will talk
> about this for sure.
Looking forward to it.