[Osr-101] What's the Neutron-Auth header good for?

[Thomas Comiotto]

Hi Andi

Am 08.08.2006 um 18:45 schrieb Andreas Wuest:

> Hi
>
> On 8.8.2006 12:04 Uhr, Thomas Comiotto wrote:
>
>>> it's not about  the client, but about the server. If the server just 
>>> receives a regular GET request how should it be able to out figure
>>> what kind of authentication the client supports. If you can answer 
>>> me this question then I am happy to remove it, but we have discussed
>>> this several times and nobody had an answer.
>>>
>> No. We did discuss and even made a point I think. But you didn't 
>> agree (or maybe you just didn't listen).
>> The server has to know that it deals with a neutron request not only 
>> in case of authentication. So how do you deal with that? You do so by 
>> either looking at the user-agent header
>
> That may not be the best idea, since we really shouldn't go on and 
> mess with the user-agent string when using a host application (like 
> Ulysses currently does, being an extension to Firefox), because other 
> extensions might be messing with that string as well. So it may not be 
> a reliable way of telling the server who we are.
>

Understood!


>> or by assuming that all command urls given by some  introspection 
>> file are requested by a neutron client. As I said before and as Andi 
>> did too, the latter is just fine.
>
> Yes, that's basically what I said sometime ago: if the client was able 
> to access that certain URI, this means that the client must be 
> Neutron-enabled, because otherwise it wouldn't even know about that 
> URI in the first place.
>
> Now, the counterargument was that the server then has to have some 
> logic to distinguish URIs, i.e. it has to know that /index.html can be 
> accessed by normal clients as well as Neutron-enabled clients, whereas 
> /foo.html can only be accessed by Neutron-enabled clients. AFAIR, this 
> was said to create major suckage for the server, and it would 
> therefore be easier if the client would reveal itself using a header 
> field.
>

Heh:) I'd consider inconsistent implementation strategies major 
suckage; foo.html can only be a accessed by whatever  clients in case 
of a plain GET request (open). In case of all other supported commands 
there's no way but providing neutron specific access points because you 
will want to send exception messages back to the client (without 
letting the client signal it's willingness to accept them beforehand 
btw).

This might well be a server issue but still, client side integrators 
will wonder why they suddenly have to set a http header for what 
otherwise seems to be dealt with automagically by the server: recieving 
a neutron specific response.


--
Bests
Thomas