From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.204.72.79 with SMTP id l15cs167022bkj; Mon, 15 Jun 2009 14:04:00 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com designates 10.142.49.20 as permitted sender) client-ip=10.142.49.20; Authentication-Results: mr.google.com; spf=pass (google.com: domain of grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com designates 10.142.49.20 as permitted sender) smtp.mail=grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com; dkim=pass header.i=grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com Received: from mr.google.com ([10.142.49.20]) by 10.142.49.20 with SMTP id w20mr10279296wfw.8.1245099839199 (num_hops = 1); Mon, 15 Jun 2009 14:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:received:x-sender:x-apparently-to :mime-version:received:date:in-reply-to:x-ip:references:user-agent :x-http-useragent:message-id:subject:from:to:content-type :content-transfer-encoding:reply-to:sender:precedence:x-google-loop :mailing-list:list-id:list-post:list-help:list-unsubscribe :x-beenthere-env:x-beenthere; bh=+oe7U81bwt8JJzdAy/JTbLHpw11O+7bwDF+zVRGeuxw=; b=YmmjXbpnFPTg2cCIpY4Du8xTi3I92QOmtLaDfWly8awVgk67D3kFCwCTl7T6rlo0Z/ m3q+MpgJsC6xd/Iq8Z9f34LsZG4nLWi042OyZ8O8A+3+ZMM4uC6enztmtUwRlh/hvB8A BpPQa4hxONwitspqMYJ2gguf0LjXVMTsUxVoQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-sender:x-apparently-to:mime-version:date:in-reply-to:x-ip :references:user-agent:x-http-useragent:message-id:subject:from:to :content-type:content-transfer-encoding:reply-to:sender:precedence :x-google-loop:mailing-list:list-id:list-post:list-help :list-unsubscribe:x-beenthere-env:x-beenthere; b=dQNPrGz9bByx4gDDmoxnaGVvJZnhLh5QuxVCnvJ6jdzwAODTUFb9o9dbO8zFGbg+aM p2IoNPZSc+MbivhY6IMn4NZrwiz/dsPitQx6RZh4ijOuViykzVXfPliA/czTBLi9c1p7 MBGNm/UNrCvW+wMbQch09Om2TOJOSf8ZrOfEI= Received: by 10.142.49.20 with SMTP id w20mr1362324wfw.8.1245099839000; Mon, 15 Jun 2009 14:03:59 -0700 (PDT) Received: by 10.106.129.7 with SMTP id b7gr1452prd.0; Mon, 15 Jun 2009 14:03:56 -0700 (PDT) X-Sender: martin.aumont@gmail.com X-Apparently-To: rack-devel@googlegroups.com MIME-Version: 1.0 Received: by 10.100.135.11 with SMTP id i11mr397025and.27.1245099835797; Mon, 15 Jun 2009 14:03:55 -0700 (PDT) Date: Mon, 15 Jun 2009 14:03:55 -0700 (PDT) In-Reply-To: X-IP: 69.196.138.211 References: <39345448-fc33-4712-8159-6da93fe9a189@h18g2000yqj.googlegroups.com> <299c839d0906140650n1849c528of36a6fee066a4a35@mail.gmail.com> <245fb4700906140839h963cdc5k7c4c83d262931bf5@mail.gmail.com> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009060308 Ubuntu/9.04 (jaunty) Firefox/3.0.11,gzip(gfe),gzip(gfe) Message-ID: <51b72270-d718-417a-aa65-d1db71c1dd31@g15g2000pra.googlegroups.com> Subject: Re: Request#accept_media_types From: mynyml To: Rack Development Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Reply-To: rack-devel@googlegroups.com Sender: rack-devel@googlegroups.com Precedence: bulk X-Google-Loop: groups Mailing-List: list rack-devel@googlegroups.com; contact rack-devel+owner@googlegroups.com List-Id: List-Post: List-Help: List-Unsubscribe: , X-BeenThere-Env: rack-devel@googlegroups.com X-BeenThere: rack-devel@googlegroups.com @Joshua: Nice catch about the quality values. The specs do specify they can contain up to three decimal digits. I updated the code to reflect that. Now about Apache's behaviour of assigning 0.01 to */* and 0.02 to type/ *: I didn't know about this so I did some reading. Seems that Apache does that as a fix for browsers that don't send any quality values at all, as it assumes they don't really know what they're doing. http://httpd.apache.org/docs/1.3/content-negotiation.html#better Turns out though there is another part of the HTTP spec (that I had previously missed), which is that more specific types override less specific ones. This automatically takes care of apache's behaviour. I updated the code to include this too. @Ryan: The code was becoming too repetitive so I split the media type handling into it's own class. I put it in Rack::Mime::MimeType. I guess that could provide a starting point. It could eventually subclass something more generic. @Yehuda: TBH I don't think I know enough performance optimization tricks to add significant improvements, but I added the basics by caching the parsed output. Latest patch is @ http://github.com/mynyml/rack/commit/2f0a743fe3a55b07cf0fc75ba06cb3180dde= f7be Questions, suggestions, patches? Anyone wants to tackle performance? =3D) On Jun 15, 3:58=A0pm, Ryan Tomayko wrote: > I haven't reviewed the patch yet but I'd love to have a set of simple > utility classes/methods/mixins for parsing basic HTTP header value > types. Accept, Accept-Language, Accept-Encoding, Cache-Control, etc. > all follow a few simple syntax grammars. We could then use the > utilities from Rack::Request, or directly from framework/app code if > more control is needed. > > Ryan > > On Sun, Jun 14, 2009 at 8:39 AM, Yehuda Katz wrote: > > Take a look at what we do in Merb. We've optimized our Accept header pa= rsing > > quite a bit (for performance; it can be shockingly slow), and handle qu= ality > > factors (both absolute and relative). > > > -- Yehuda > > > On Sun, Jun 14, 2009 at 9:50 AM, Joshua Hull wrot= e: > > >> Just a couple of comments on this: > > >> types =3D 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 =3D types.select {|type| quality =3D media_type_quality(type); > >> quality > 0 && quality <=3D 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 wrote= : > > >> > Patch is at: > >> >http://github.com/mynyml/rack/commit/c9953dbc3f834fdcbcd1ebc8b71b64ea= ... > >> > ----- > >> > 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 a= n > >> > 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 dow= n > >> > 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/3f42d3afe7323d322567d77cd404= ... > >> > ohttp://github.com/mynyml/rack-abstract-format > >> > ohttp://github.com/mynyml/rack-supported-media-types > >> > ohttp://github.com/mynyml/rack-js4xhr > >> > ohttp://github.com/mynyml/rack-respond_to > > >> > which led me to write the Accept header parsing code: > > >> > ohttp://github.com/mynyml/rack-accept-media-types > > >> > In my rack clone, the request_accept branch is a straight port of th= e > >> > 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 > > > -- > > Yehuda Katz > > Developer | Engine Yard > > (ph) 718.877.1325 > >