Alberto Valverde wrote:
> 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.

I don't think so.  This bit of RFC compliance might be expected by the client 
of a particular application, and a particular application might want to satisfy 
that expectation, but I don't think it's BFG's job to mandate that it must; 
instead we just want to allow application developers to make that decision 
themselves by allowing them to register a less specific view (one *without* an 
accepts=) that perhaps returns a 406.

> 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....

I think view lookup should continue even if views are registered with accept 
predicates and found, but none of those view match.

- C
Repoze-dev mailing list

Reply via email to