 |
 |
Hi All, >> - 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 >> kxr_redirect. > 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 rul;es. 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. Andy