Rob Sanderson writes:
>>>> But a nice thing about the current proposal is that it greatly
>>>> reduced the frequency with which you have to send a clear-text
>>>> user/password pair across the network. That may be worth
>>>> something.
>>>
>>> Also, please note that there's nothing /preventing/ the client
>>> from sending the username and password on every request if you
>>> don't care about sessions. A session based server might create a
>>> bunch of different sessions that are never used, but with an
>>> appropriately short timeout or some simple checking for this
>>> behaviour would avoid overload.
>>
>> Am I correct assuming the server can also issue the token or
>> session id without the client sending authentication information if
>> authentication isn't needed?
>
> Unfortunately not.
>
> There's a restriction that servers must only send extra data fields
> (extraResponseData in this case) when they have been requested by
> the client.
... but there's nothing stopping us from defining an extension by
which the client can request a session-cookie without asserting the
user's identity. So just
x-give-me-a-cookie=1
with no username or password included.
Ray Denenberg writes:
>> There's a restriction that servers must only send extra data fields
>> (extraResponseData in this case) when they have been requested by
>> the client.
>
> But the client can overide this restriction. See
> http://www.loc.gov/standards/sru/accept.html
While this is true, I think that "overide this restriction" is a very
misleading way to express it. Something like "the client can open
itself up to being spammed by floods of unsolicited packets" would be
more apropos :-)
_/|_ ___________________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ The difference between C and Java is the difference between
"int i" and "public static final transient volatile synchronized
Integer theTemporaryLoopCounter".
|