Alberto Valverde wrote:
> Chris McDonough wrote:
>> Alberto Valverde wrote:
>>> 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:
>>> 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  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
I think view lookup should continue even if views are registered with accept
predicates and found, but none of those view match.
Repoze-dev mailing list