Add support for RFC5988 Link header #528

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
Contributor

alekstorm commented Jun 4, 2012

Add RequestHandler.link, RequestHandler.hint. This allows applications to easily hint to the client which resources are related to a response, to cut down on request latency, as recommended by http://dev.chromium.org/spdy/link-headers-and-server-hint.

Add support for RFC5988 Link header
Add RequestHandler.link, RequestHandler.hint
Owner

bdarnell commented Jun 13, 2012

I'm not sure that these headers really warrant special methods; I'd
rather not establish a precedent of methods to construct values for
every nontrivial header. I definitely think hint is unnecessary; link is just
complicated enough that I can see some value (although the name is too
vague and likely to collide with names used in subclasses). Except
for the angle brackets around the url, this could be done with an
extension of set_header that supports the semicolon-delimited options
seen in many headers.

Also, why a list of pairs instead of a dict? Are there cases where
duplicates are allowed or order matters? I'd prefer to support dicts
for the common case, with lists of pairs as an option if needed.

Contributor

alekstorm commented Jun 18, 2012

On Tue, Jun 12, 2012 at 11:36 PM, bdarnell reply@reply.github.com wrote:

I'm not sure that these headers really warrant special methods; I'd
rather not establish a precedent of methods to construct values for
every nontrivial header. I definitely think hint is unnecessary; link is
just
complicated enough that I can see some value (although the name is too
vague and likely to collide with names used in subclasses).

hint() is useful in SPDY - it's mentioned in the spec. I figured a
convenience method would encourage people to actually use it; I'll take it
out.

Except
for the angle brackets around the url, this could be done with an
extension of set_header that supports the semicolon-delimited options
seen in many headers.

Hm, never thought to generalize it. The syntaxes for the different headers
differ subtly, but that might work.

Also, why a list of pairs instead of a dict? Are there cases where
duplicates are allowed or order matters? I'd prefer to support dicts
for the common case, with lists of pairs as an option if needed.

Yes, duplicates are allowed for some options. You're saying we should
detect whether a dict or a list has been passed? Doesn't seem very
Pythonic. How about a dict of lists?

Owner

bdarnell commented Jun 25, 2012

Yeah, I suspected there might be subtle differences in the different header syntaxes. Do you think there's enough commonality that a shared implementation would be useful?

There is precedent for type-checking to allow either dicts or lists of pairs as arguments (the examples that come to mind are the dict constructor itself and urllib.urlencode). I think type-checking would be more pythonic than a dict of lists, since a dict of lists impacts every call even when the common case is a one-to-one mapping.

@bdarnell bdarnell added the web label Jul 16, 2014

@bdarnell bdarnell closed this Jul 5, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment