HTTP Accept header question (for Zend\Http\Header namespace)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

HTTP Accept header question (for Zend\Http\Header namespace)

David Joly
Hey All,

I was working on the multi-value headers last night (Accept, Accept-Charset, etc).In so doing I'm trying to decipher the Accept header (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html).

The following example has me confused:

The media type quality factor associated with a given type is determined by finding the media range with the highest precedence which matches that type. For example,
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5
would cause the following values to be associated:
text/html;level=1         = 1 text/html                 = 0.7 text/plain                = 0.3
image/jpeg                = 0.5 text/html;level=2         = 0.4 text/html;level=3         = 0.7
Note: A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user.


The client uses the accept header to specify what content types are preferred, acceptable, and not acceptable in the response. I understand this purpose of the header and sorting by the q-factor. What I don't understand:

1) Why the content type 'text/html' is included in the above header more than once, and 

2) How the level parameter is used. From the above example, the level parameter appears to be part of the value itself, rather than something used to determine the value/content type preference.

Hopefully someone can clear this up for me.

Regards,

David
 
 
David Joly
http://www.linkedin.com/in/davidpjoly 
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Accept header question (for Zend\Http\Header namespace)

weierophinney
Administrator
-- David Joly <[hidden email]> wrote
(on Friday, 03 February 2012, 08:46 AM -0800):

> I was working on the multi-value headers last night (Accept,
> Accept-Charset, etc).In so doing I'm trying to decipher the Accept
> header (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html).
>
> The following example has me confused:
>
> The media type quality factor associated with a given type is
> determined by finding the media range with the highest precedence
> which matches that type. For example,
> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5
> would cause the following values to be associated:
> text/html;level=1         = 1 text/html                 = 0.7 text/plain                = 0.3
> image/jpeg                = 0.5 text/html;level=2         = 0.4 text/html;level=3         = 0.7
> Note: A user agent might be provided with a default set of quality
> values for certain media ranges. However, unless the user agent is a
> closed system which cannot interact with other rendering agents, this
> default set ought to be configurable by the user.
>
>
> The client uses the accept header to specify what content types are
> preferred, acceptable, and not acceptable in the response. I
> understand this purpose of the header and sorting by the q-factor.
> What I don't understand:
>
> 1) Why the content type 'text/html' is included in the above header
>    more than once, and 
>
> 2) How the level parameter is used. From the above example, the level
>    parameter appears to be part of the value itself, rather than
>    something used to determine the value/content type preference.
>
> Hopefully someone can clear this up for me.

I actually have tackled this already in my feature/view-layer branch
(you can view it here: http://bit.ly/wu4ekp); that said, it's incomplete
(I don't address level -- more on that below), and it needs to be
adapted to each of the other Accept-* types.

There are two things at play, basically. The q-factor is the one most
looked at. However, you can also specify a "level", and these CAN also
act like priorities, but operate in the order of decreasing precedence
(i.e., level 1 is higher priority than level 2). The examples they have
in the spec are contrived, and, tbh, confusing at best, for the very
reason you mention: the text/html entry with highest priority will be
selected first.

Another documented use case for the "level" is to indicate the _version_
of the type. As an example, a "level 1" might indicate the first version
of that spec available. In such cases, it wouldn't be a priority, but
instead a _descriptor_ -- so in the example you have above, the earlier
version of the text/html spec (level=1) is prioritized over a later
version (level=2) -- which means that if you support level=2 in your
application but not level=1, you'd be able to select it only if you
cannot support any other types with higher priority.

Unfortunately, the "level" selector has conflicting meanings, so I'm not
100% sure we should support it by default; "q", on the other hand, is
well documented.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: HTTP Accept header question (for Zend\Http\Header namespace)

David Joly
Hi Matthew,

Thanks for the quick response.

"Another documented use case for the "level" is to indicate the _version_of the type. As an example, a "level 1" might indicate the first version
of that spec available."

This is the only thing I could think of myself given the example. Do you have any links to additional documentation on that? My searches on Google have been rather unfruitful.

I'll definitely take a look at your branch, thanks for the link.
 
David Joly
http://www.linkedin.com/in/davidpjoly 


________________________________
 From: Matthew Weier O'Phinney <[hidden email]>
To: [hidden email]
Sent: Friday, February 3, 2012 11:09 AM
Subject: Re: [zf-contributors] HTTP Accept header question (for Zend\Http\Header namespace)
 
-- David Joly <[hidden email]> wrote
(on Friday, 03 February 2012, 08:46 AM -0800):

> I was working on the multi-value headers last night (Accept,
> Accept-Charset, etc).In so doing I'm trying to decipher the Accept
> header (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html).
>
> The following example has me confused:
>
> The media type quality factor associated with a given type is
> determined by finding the media range with the highest precedence
> which matches that type. For example,
> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5
> would cause the following values to be associated:
> text/html;level=1         = 1 text/html                 = 0.7 text/plain                = 0.3
> image/jpeg                = 0.5 text/html;level=2         = 0.4 text/html;level=3         = 0.7
> Note: A user agent might be provided with a default set of quality
> values for certain media ranges. However, unless the user agent is a
> closed system which cannot interact with other rendering agents, this
> default set ought to be configurable by the user.
>
>
> The client uses the accept header to specify what content types are
> preferred, acceptable, and not acceptable in the response. I
> understand this purpose of the header and sorting by the q-factor.
> What I don't understand:
>
> 1) Why the content type 'text/html' is included in the above header
>    more than once, and 
>
> 2) How the level parameter is used. From the above example, the level
>    parameter appears to be part of the value itself, rather than
>    something used to determine the value/content type preference.
>
> Hopefully someone can clear this up for me.

I actually have tackled this already in my feature/view-layer branch
(you can view it here: http://bit.ly/wu4ekp); that said, it's incomplete
(I don't address level -- more on that below), and it needs to be
adapted to each of the other Accept-* types.

There are two things at play, basically. The q-factor is the one most
looked at. However, you can also specify a "level", and these CAN also
act like priorities, but operate in the order of decreasing precedence
(i.e., level 1 is higher priority than level 2). The examples they have
in the spec are contrived, and, tbh, confusing at best, for the very
reason you mention: the text/html entry with highest priority will be
selected first.

Another documented use case for the "level" is to indicate the _version_
of the type. As an example, a "level 1" might indicate the first version
of that spec available. In such cases, it wouldn't be a priority, but
instead a _descriptor_ -- so in the example you have above, the earlier
version of the text/html spec (level=1) is prioritized over a later
version (level=2) -- which means that if you support level=2 in your
application but not level=1, you'd be able to select it only if you
cannot support any other types with higher priority.

Unfortunately, the "level" selector has conflicting meanings, so I'm not
100% sure we should support it by default; "q", on the other hand, is
well documented.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: HTTP Accept header question (for Zend\Http\Header namespace)

weierophinney
Administrator
-- David Joly <[hidden email]> wrote
(on Friday, 03 February 2012, 10:00 AM -0800):

> Hi Matthew,
>
> Thanks for the quick response.
>
> "Another documented use case for the "level" is to indicate the _version_
> of the type. As an example, a "level 1" might indicate the first version
> of that spec available."
>
> This is the only thing I could think of myself given the example. Do you have
> any links to additional documentation on that? My searches on Google have been
> rather unfruitful.

The Apache docs, actually:

    http://httpd.apache.org/docs/2.2/content-negotiation.html

Look for the header "Apache Negotiation Algorithm", point 2.4.

> I'll definitely take a look at your branch, thanks for the link.
>  
> David Joly http://www.linkedin.com/in/davidpjoly 
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> From: Matthew Weier O'Phinney <[hidden email]>
> To: [hidden email]
> Sent: Friday, February 3, 2012 11:09 AM
> Subject: Re: [zf-contributors] HTTP Accept header question (for Zend\Http\
> Header namespace)
>
> -- David Joly <[hidden email]> wrote
> (on Friday, 03 February 2012, 08:46 AM -0800):
> > I was working on the multi-value headers last night (Accept,
> > Accept-Charset, etc).In so doing I'm trying to decipher the Accept
> > header (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html).
> >
> > The following example has me confused:
> >
> > The media type quality factor associated with a given type is
> > determined by finding the media range with the highest precedence
> > which matches that type. For example,
> > Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q
> =0.4, */*;q=0.5
> > would cause the following values to be associated:
> > text/html;level=1        = 1 text/html                = 0.7 text/plain      
>         = 0.3
> > image/jpeg                = 0.5 text/html;level=2        = 0.4 text/html;
> level=3        = 0.7
> > Note: A user agent might be provided with a default set of quality
> > values for certain media ranges. However, unless the user agent is a
> > closed system which cannot interact with other rendering agents, this
> > default set ought to be configurable by the user.
> >
> >
> > The client uses the accept header to specify what content types are
> > preferred, acceptable, and not acceptable in the response. I
> > understand this purpose of the header and sorting by the q-factor.
> > What I don't understand:
> >
> > 1) Why the content type 'text/html' is included in the above header
> >    more than once, and
> >
> > 2) How the level parameter is used. From the above example, the level
> >    parameter appears to be part of the value itself, rather than
> >    something used to determine the value/content type preference.
> >
> > Hopefully someone can clear this up for me.
>
> I actually have tackled this already in my feature/view-layer branch
> (you can view it here: http://bit.ly/wu4ekp); that said, it's incomplete
> (I don't address level -- more on that below), and it needs to be
> adapted to each of the other Accept-* types.
>
> There are two things at play, basically. The q-factor is the one most
> looked at. However, you can also specify a "level", and these CAN also
> act like priorities, but operate in the order of decreasing precedence
> (i.e., level 1 is higher priority than level 2). The examples they have
> in the spec are contrived, and, tbh, confusing at best, for the very
> reason you mention: the text/html entry with highest priority will be
> selected first.
>
> Another documented use case for the "level" is to indicate the _version_
> of the type. As an example, a "level 1" might indicate the first version
> of that spec available. In such cases, it wouldn't be a priority, but
> instead a _descriptor_ -- so in the example you have above, the earlier
> version of the text/html spec (level=1) is prioritized over a later
> version (level=2) -- which means that if you support level=2 in your
> application but not level=1, you'd be able to select it only if you
> cannot support any other types with higher priority.
>
> Unfortunately, the "level" selector has conflicting meanings, so I'm not
> 100% sure we should support it by default; "q", on the other hand, is
> well documented.
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [hidden email]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>
>

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: HTTP Accept header question (for Zend\Http\Header namespace)

Dolf Schimmel
Imagine the level parameter could be replaced by a 'version' parameter. You
may like to prefer your xml using 'version=2', then just plain json, after
that xml with 'version = 1', and lastly text/*.

We've been using this code at Enrise (www.enrise.com) for a while now, and
it's proven to suffice. Been wanting to open source it in our framework
(built on top of ZF), Glitch: https://github.com/Enrise/Glitch

However, I've unfortunately not gotten to do so, so here's the code in case
you like it. https://gist.github.com/1731637

Dolf
-- Freeaqingme

On Fri, Feb 3, 2012 at 7:16 PM, Matthew Weier O'Phinney <[hidden email]>wrote:

> -- David Joly <[hidden email]> wrote
> (on Friday, 03 February 2012, 10:00 AM -0800):
> > Hi Matthew,
> >
> > Thanks for the quick response.
> >
> > "Another documented use case for the "level" is to indicate the _version_
> > of the type. As an example, a "level 1" might indicate the first version
> > of that spec available."
> >
> > This is the only thing I could think of myself given the example. Do you
> have
> > any links to additional documentation on that? My searches on Google
> have been
> > rather unfruitful.
>
> The Apache docs, actually:
>
>    http://httpd.apache.org/docs/2.2/content-negotiation.html
>
> Look for the header "Apache Negotiation Algorithm", point 2.4.
>
> > I'll definitely take a look at your branch, thanks for the link.
> >
> > David Joly http://www.linkedin.com/in/davidpjoly
> >
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> > From: Matthew Weier O'Phinney <[hidden email]>
> > To: [hidden email]
> > Sent: Friday, February 3, 2012 11:09 AM
> > Subject: Re: [zf-contributors] HTTP Accept header question (for
> Zend\Http\
> > Header namespace)
> >
> > -- David Joly <[hidden email]> wrote
> > (on Friday, 03 February 2012, 08:46 AM -0800):
> > > I was working on the multi-value headers last night (Accept,
> > > Accept-Charset, etc).In so doing I'm trying to decipher the Accept
> > > header (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html).
> > >
> > > The following example has me confused:
> > >
> > > The media type quality factor associated with a given type is
> > > determined by finding the media range with the highest precedence
> > > which matches that type. For example,
> > > Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
> text/html;level=2;q
> > =0.4, */*;q=0.5
> > > would cause the following values to be associated:
> > > text/html;level=1        = 1 text/html                = 0.7 text/plain
> >         = 0.3
> > > image/jpeg                = 0.5 text/html;level=2        = 0.4
> text/html;
> > level=3        = 0.7
> > > Note: A user agent might be provided with a default set of quality
> > > values for certain media ranges. However, unless the user agent is a
> > > closed system which cannot interact with other rendering agents, this
> > > default set ought to be configurable by the user.
> > >
> > >
> > > The client uses the accept header to specify what content types are
> > > preferred, acceptable, and not acceptable in the response. I
> > > understand this purpose of the header and sorting by the q-factor.
> > > What I don't understand:
> > >
> > > 1) Why the content type 'text/html' is included in the above header
> > >    more than once, and
> > >
> > > 2) How the level parameter is used. From the above example, the level
> > >    parameter appears to be part of the value itself, rather than
> > >    something used to determine the value/content type preference.
> > >
> > > Hopefully someone can clear this up for me.
> >
> > I actually have tackled this already in my feature/view-layer branch
> > (you can view it here: http://bit.ly/wu4ekp); that said, it's incomplete
> > (I don't address level -- more on that below), and it needs to be
> > adapted to each of the other Accept-* types.
> >
> > There are two things at play, basically. The q-factor is the one most
> > looked at. However, you can also specify a "level", and these CAN also
> > act like priorities, but operate in the order of decreasing precedence
> > (i.e., level 1 is higher priority than level 2). The examples they have
> > in the spec are contrived, and, tbh, confusing at best, for the very
> > reason you mention: the text/html entry with highest priority will be
> > selected first.
> >
> > Another documented use case for the "level" is to indicate the _version_
> > of the type. As an example, a "level 1" might indicate the first version
> > of that spec available. In such cases, it wouldn't be a priority, but
> > instead a _descriptor_ -- so in the example you have above, the earlier
> > version of the text/html spec (level=1) is prioritized over a later
> > version (level=2) -- which means that if you support level=2 in your
> > application but not level=1, you'd be able to select it only if you
> > cannot support any other types with higher priority.
> >
> > Unfortunately, the "level" selector has conflicting meanings, so I'm not
> > 100% sure we should support it by default; "q", on the other hand, is
> > well documented.
> >
> > --
> > Matthew Weier O'Phinney
> > Project Lead            | [hidden email]
> > Zend Framework          | http://framework.zend.com/
> > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> >
> > --
> > List: [hidden email]
> > Info: http://framework.zend.com/archives
> > Unsubscribe: [hidden email]
> >
> >
> >
> >
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [hidden email]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>