Re: Content-Negotiation in check referer requests

Olivier Thereaux a écrit :
> I guess it shows that
> it is safer to submit patches to the bugzilla in addition or instead of
> the list only - they don't get drowned in discussion and get addressed
> or at least looked at sooner or later.
Yes, I think I made a mistake here. I considered it, but got too shy.

> On Fri, Mar 28, 2008, Etienne Miret wrote:
>> <http://perso.ens-lyon.fr/etienne.miret/2008/03/28/negotiate-referer.diff>
>> It makes use of the already available "accept", "accept-language" and 
>> "accept-charset" parameters and populate them with the values provided 
>> by the client *in case of a referer request*. It will also make sure 
>> those values are kept across revalidation. This makes URI to be very 
>> long. Sorry.
> 
> I think this would be a welcome patch, as indeed it makes sense to
> forward accept and accept-language in case of referer validation (not
> sure, however about accept-encoding).
I didn't forward accept-encoding, for reasons I explained in my first
post. I guess you meant "accept-charset".

> The small issue about this patch is that it seems to also include additions to the UI,
No, not at all. The second patch do makes additions to the UI, but not
this one. Actually, not modifying the UI was the main reason for
providing two different patches.

To be more precise, the first patch adds some <input type="hidden"> tags
to the UI, which are invisible, in order to make sure that the "accept*"
options are kept across revalidation (whether set by hand in the URI or
added by my patch after a referrer request). That's all.

> additional options
> that not only would clutter the interface, they also seem to duplicate
> existing options (e.g why http_accept and accept?)
They do clutter the interface, I was very aware of this issue, which is
why I made two different patches. But I don't think I duplicated any
options. When writing my patch, I mainly made use of available (but
hidden) options. However, I'll check that.

> Do you think you could make a reduced patch that would only set accept
> and accept-language in the case of referer validation?
Sure, I'll send one within the end of the week.

>> The second patch is:
>> <http://perso.ens-lyon.fr/etienne.miret/2008/03/28/negotiate-all.diff>
>> This one brings full content-negotiation support to the validator, 
>> providing options for setting the Accept, Accept-Language and 
>> Accept-Charset headers on the home page (and on validation results if 
>> verbose output is selected). However, it wont send any Accept* headers 
>> by default.
> 
> Ditto above, I don't know if additional UI options for such a rare case
> is a good idea, and I think that the validator already has the feature
> with the accept and accept-language parameters:
> http://validator.w3.org/docs/users.html#Output
My UI modifications just allow to set those parameters from the UI
(which I just realized you created yourself), instead of appending them
to the URI by hand, which is much easier, specially because the user
doesn't need to %-encode them anymore. IMHO it would be a useful
addition to the UI, but I understand your point of view.

This being said, if those options are added to the UI, I think it can be
done a little better than in my patch, which I feel is quite "cluttering".

-- 
Etienne Miret
Ne m'envoyez pas de fichier Word SVP, je ne peux pas les lire !
Don't send me Word attachments please, I can't read them!
http://perso.ens-lyon.fr/etienne.miret/Netiquette/no_MS_Office

Received on Monday, 21 April 2008 12:26:44 UTC