From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.204.72.79 with SMTP id l15cs142861bkj; Fri, 19 Jun 2009 08:57:04 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com designates 10.100.95.15 as permitted sender) client-ip=10.100.95.15; Authentication-Results: mr.google.com; spf=pass (google.com: domain of grbounce-ceibQwUAAAB4YPBqaDIjI2bFOCxyyh3G=chneukirchen=gmail.com@googlegroups.com designates 10.100.95.15 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.100.95.15]) by 10.100.95.15 with SMTP id s15mr2716863anb.26.1245427023491 (num_hops = 1); Fri, 19 Jun 2009 08:57:03 -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=PE76kLcM7TFV38gyOYvoTmuIQP7sYwLXLtfsbNhOH5A=; b=ztuns3iRVPhARvzsIKKlxxd/tWUlYNsG3e2H+Oe3qYfA86OZWEaqW5a8HRX2bA/a3H /ZiKsDL9UBuJbAsPagcEAd3Awh9u75b5TnNgIvyAK/SHSDBj/V+8MxDlcLOBSkjis0tt dUqZW4Nk45oe+deGk9cr8elhWQ4eG3MBU8myc= 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=qxcl4emzPxuBktXuyVpm5mXZsX666KfUxXtq26IBhDUOFXIjxGa4NVIVNb5XP3ez50 7Al93/dmAw7Zha8J+BsAmXxGXaymXMAzJPr/11OEbLwDAhjumPeM2tfneW13w32PZVA3 wdZ3IkUeOKaxKl0goO1GZp8CXxfrGCSqX4gwE= Received: by 10.100.95.15 with SMTP id s15mr368637anb.26.1245427023279; Fri, 19 Jun 2009 08:57:03 -0700 (PDT) Received: by 10.177.2.5 with SMTP id e5gr1463yqi.0; Fri, 19 Jun 2009 08:55:45 -0700 (PDT) X-Sender: martin.aumont@gmail.com X-Apparently-To: rack-devel@googlegroups.com MIME-Version: 1.0 Received: by 10.100.45.9 with SMTP id s9mr364310ans.15.1245426942640; Fri, 19 Jun 2009 08:55:42 -0700 (PDT) Date: Fri, 19 Jun 2009 08:55:42 -0700 (PDT) In-Reply-To: <51b72270-d718-417a-aa65-d1db71c1dd31@g15g2000pra.googlegroups.com> X-IP: 69.196.138.211 References: <39345448-fc33-4712-8159-6da93fe9a189@h18g2000yqj.googlegroups.com> <299c839d0906140650n1849c528of36a6fee066a4a35@mail.gmail.com> <245fb4700906140839h963cdc5k7c4c83d262931bf5@mail.gmail.com> <51b72270-d718-417a-aa65-d1db71c1dd31@g15g2000pra.googlegroups.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: 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 Did anyone get a chance to take a look at the updated patch? Any more suggestions? Thanks On Jun 15, 5:03=A0pm, mynyml wrote: > @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. > > =A0http://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 @ > =A0http://github.com/mynyml/rack/commit/2f0a743fe3a55b07cf0fc75ba06cb318.= .. > > 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 = parsing > > > quite a bit (for performance; it can be shockingly slow), and handle = quality > > > factors (both absolute and relative). > > > > -- Yehuda > > > > On Sun, Jun 14, 2009 at 9:50 AM, Joshua Hull wr= ote: > > > >> 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 wro= te: > > > >> > Patch is at: > > >> >http://github.com/mynyml/rack/commit/c9953dbc3f834fdcbcd1ebc8b71b64= ea... > > >> > ----- > > >> > Patch to add parsing of the HTTP_ACCEPT header's media types. Orde= rs > > >> > 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 al= so > > >> > ignores the Accept hierarchy, which can be usefull for cascading d= own > > >> > possible handlings of the resquest (think of a respond_to mechanis= m, > > >> > for instance). > > > >> > I've encountered many use cases already: > > > >> > o > > >> >http://github.com/rack/rack-contrib/blob/3f42d3afe7323d322567d77cd4= 04... > > >> > 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 = 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 > > > > -- > > > Yehuda Katz > > > Developer | Engine Yard > > > (ph) 718.877.1325 > >