Just a couple of comments on this:
types = types.select {|type| media_type_quality(type).between?(0.1, 1) }
this should probably check that its greater than 0 and less than or
equal to 1 instead
types = types.select {|type| quality = media_type_quality(type);
quality > 0 && quality <= 1 }
so that values of 0.01 still get through.
As well, the default value of all types is 1.0, but we probably want
to do something similar to what apache does, and assign */* a value of
0.01 and type/* a value of 0.02.
Cheers
Joshua
On Fri, Jun 12, 2009 at 5:48 PM, mynyml<martin.aumont@gmail.com> wrote:
>
> Patch is at: http://github.com/mynyml/rack/commit/c9953dbc3f834fdcbcd1ebc8b71b64eaf24d9e2b
> -----
> Patch to add parsing of the HTTP_ACCEPT header's media types. Orders
> types by "quality" (preference level) (following HTTP 1.1 specs).
>
> The main advantage of being able to parse the Accept header is to
> centralize the lookup for the request's "desired" type(s). Usually, a
> client asks for a specific media type to be sent back by appending an
> extension to the URL; not only does this require parsing by every
> middleware/app that needs to know about this media type, but it also
> ignores the Accept hierarchy, which can be usefull for cascading down
> possible handlings of the resquest (think of a respond_to mechanism,
> for instance).
>
> I've encountered many use cases already:
>
> o http://github.com/rack/rack-contrib/blob/3f42d3afe7323d322567d77cd404fb5bd8d9f1eb/lib/rack/contrib/accept_format.rb
> o http://github.com/mynyml/rack-abstract-format
> o http://github.com/mynyml/rack-supported-media-types
> o http://github.com/mynyml/rack-js4xhr
> o http://github.com/mynyml/rack-respond_to
>
> which led me to write the Accept header parsing code:
>
> o http://github.com/mynyml/rack-accept-media-types
>
> In my rack clone, the request_accept branch is a straight port of the
> rack-accept-media-types gem, and the request_accept-compact branch
> minimizes the code into two methods (instead of two classes). The
> latter reflects the rest of the Request class much better so it's
> probably a more appropriate patch.
>
> Feedback/questions/suggestions ?
>
> Thanks