Chris McDonough wrote:
> Alberto Valverde wrote:
>> Hello,
>>
>> I'm trying to make use of the new-in-1.1 "accept" view predicate to 
>> register several views with the same name for the same context object 
>> to render a response in the content-type requested by the user but 
>> the result is not quite what I expect. The zcml looks like this:
>>
>>  <view
>>     for="sigym.propag.interfaces.IPropagator"
>>     permission="view"
>>     request_method="GET"
>>     accept="text/html"
>>     renderer="sigym.ogcserver:views/templates/index.html"
>>     />
>>  <view
>>     for="sigym.propag.interfaces.IPropagator"
>>     view="sigym.ogcserver.views.viewpanels.config_view"
>>     permission="view"
>>     request_method="GET"
>>     accept="application/json+xconfig"
>>     renderer="json"
>>     />
>>  <view
>>     for="sigym.propag.interfaces.IPropagator"
>>     view=".views.list_propagations"
>>     permission="view"
>>     request_method="GET"
>>     accept="application/json"
>>     renderer="json"
>>     />
>>
>> Everything works fine when I request the application/json and 
>> application/json+xconfig mimetypes with a xhr since I can control the 
>> "Accept" header, however, when a browser makes a "normal" request the 
>> result is unpredictable (in practice) since '*/* is sent in the 
>> accept header so all of the view predicates evaluate positively.
>>
>> I made a quick POC patch so the best match is taken into account 
>> (attached). It modifies MultiView.__call__() so it narrows down the 
>> predicates that it will evaluate using the 
>> request.accept.best_match() method and it seems to work (all bfg 
>> tests still pass and the result is as expected when I manually test 
>> my bfg app). The patch is against the 1.1 branch in SVN.
>>
>> Is this the right approach? If so I would like to finish it up with 
>> tests to reach full coverage and contribute it :)
>
> Thanks a lot for the patch!  This is definitely something that we 
> should be accounting for.  I'm not sure that the patch is exactly 
> right; if there are "views_for_mimes", even if the current 
> configuration doesn't have a view that matches the "best" accept 
> header, it should continue trying to look for other views that don't 
> specify an accept argument instead of raising a NotFound I think.  At 
> least I think.  Let me think on it a little bit.
Hmm, after thinking more about it and reading the relevant section of 
the http spec [1] I found this snippet:

"... If no Accept header field is present, then it is assumed that the 
client accepts all media types. If an Accept header field is present, 
and if the server cannot send a response which is acceptable according 
to the combined Accept field value, then the server SHOULD send a 406 
(not acceptable) response...."

Which I think it means that the rest of the views (those with no accept 
predicate) should not be checked since the client explicitly asked for a 
content-type and no view has declared that it can provide it. In this 
case, according to the spec, I think, a 406 response should be returned 
instead of raising a NotFound.

So perhaps we should consider what's the desired behavior in this 
scenario? I mean, the meaning of not declaring an "accept" predicate 
*when* other possible candidates have. Should it be "*/*" and continue 
searching or the opposite? Hmm, I think you're right since "*/*" is the 
meaning when no candidate has declared it which I guess it's more 
intuitive....

Alberto

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Reply via email to