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
