-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor and improve media type negotiation #14
Conversation
Here's the output of
|
8d8be42
to
b09cbac
Compare
b09cbac
to
5865e3e
Compare
# e.g. client requested `/foo.json` but `/foo.spt` has no JSON page | ||
|
||
if dispatch_accept is not None: | ||
# If the extension is unknown, raise NotFound |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this our previous behavior? I might think that /foo.random-blah
should get served by the default type rather than 404ing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I think the previous behavior was inconsistent, as dispatch_accept
would be None
, so accept
would be set to accept_header
, and thus it could: return a 406, or choose a type from the Accept header which that doesn't match the extension in the URL path, or fall back to the first available type.
I think we do want to return a 404. If the developer wants to use a custom extension they can register it in the mimetypes
module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of the case where there's a dot in the final path part that's not intended to indicate a file extension. @kaguillera is questioning whether "you'd really have that situation." :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
E.g., if instead of https://tools.ietf.org/html/rfc7231#section-5.3.2 it were https://tools.ietf.org/html/rfc7231/5.3.2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it's possible to hit this corner case, but only if you're parsing request.path.raw
yourself instead of using the features that are meant to allow capturing variable data from the path: wildcards and "rfc2396 params".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking of law browsers such as http://www.ecode360.com/AM2259 or http://www.ecfr.gov/cgi-bin/text-idx?SID=a457db49113d5f8ca45f5252dd7dced0&mc=true&node=se31.3.1010_1100&rgn=div8. You might have on the filesystem:
www/%section.spt
Maybe you are parsing request.path['section']
further, or maybe you're passing it through to a database (SELECT * FROM sections WHERE section=%s
).
I agree it's an edge case, and I'm okay with merging this PR as-is and revisiting if/when we hit this edge case in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A wildcard like %section.spt
shouldn't be affected, the dispatcher isn't supposed to set extra['accept']
in that case (maybe we need a test for that?).
I'm not convinced that a single |
Are you convinced that it's at least as clear? :-) |
I'm ready to merge this if you can live with the single- |
It seems to me that not returning immediately makes it less clear that the negotiation is finished. You have to read the rest of the code to figure out that it's not doing anything else. This is probably more evident for the first I can live with the single |
Here's a statement of the conventional wisdom that minimizing How about 5ab64d7? |
(... and d374ce9? :) |
That actually looks worse to me. /o\ I found bugs by putting all the negotiation code together, I'm wary of splitting it back into multiple functions. Also, the The SO answer you linked to says that "In certain routines, once you know the answer, you want to return it to the calling routine immediately". I think that applies here, but I'd rather have the single return than the multiple functions. |
d374ce9
to
5865e3e
Compare
Okay, then! :-) I've pushed the last four commits off the branch. Ready to go? |
Oh, okay. |
The original idea was to move the negotiation to an algorithm function, but in the end I put it in
Dynamic.render()
instead. Either way moving it out of the simplates module should help us with AspenWeb/salon#13.This PR adds a few tests and fixes a few issues, it should notably make https://github.com/liberapay/liberapay.com/blob/2c03dbfd75e9a747b309bfad64590a0e2aceca05/liberapay/__init__.py#L67-L74 obsolete.