Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 54811 invoked from network); 13 Apr 2010 18:21:51 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 13 Apr 2010 18:21:51 -0000 Received: (qmail 45042 invoked by uid 500); 13 Apr 2010 18:21:48 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 45019 invoked by uid 500); 13 Apr 2010 18:21:48 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 45011 invoked by uid 99); 13 Apr 2010 18:21:48 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Apr 2010 18:21:48 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mearns.b@gmail.com designates 209.85.223.182 as permitted sender) Received: from [209.85.223.182] (HELO mail-iw0-f182.google.com) (209.85.223.182) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Apr 2010 18:21:42 +0000 Received: by iwn12 with SMTP id 12so4380091iwn.24 for ; Tue, 13 Apr 2010 11:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:content-type :content-transfer-encoding; bh=kBtX/Jf71zir/Wj+YwnTTxdkOg2EbmflcAraDZgZj3g=; b=WNY+D4I0ajx5GeK85synfoF6O4bfi8wo/yUzfAIvFC9AwUOO6Tr2FHGqlUCrXBHyOs qVV0/7s6+7NQe/lDlxMBoQjBqDQbJQyJ8L0YmCkPJ3Jy0gkkULtEyRFt6NaSG9kUkO0R Gc8XYgQWCzZiH9UpEUbo5iGd1VVKGNwONStM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=VSoQASq4fZhsLM54vZ8MdlmNm30M1DiC/u5eBxCcROrvtssyiqGvK297UudkO+ejIG NP0G8Ids1VrqUahXwT6glYbVddZlncPfIUZLvhKbpPaZC6pMmdLfKBJHcsu+JEQKEttl s6G4NmvU6FKs0qgc348+aPflg6EBAQ6F1fg74= MIME-Version: 1.0 Received: by 10.231.184.8 with HTTP; Tue, 13 Apr 2010 11:20:59 -0700 (PDT) In-Reply-To: References: From: Brian Mearns Date: Tue, 13 Apr 2010 14:20:59 -0400 Received: by 10.231.174.137 with SMTP id t9mr1197657ibz.98.1271182879230; Tue, 13 Apr 2010 11:21:19 -0700 (PDT) Message-ID: To: users@httpd.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Subject: Re: [users@httpd] Custom ETags On Tue, Apr 13, 2010 at 2:13 PM, Jonathan Zuckerman wrote: > On Tue, Apr 13, 2010 at 1:20 PM, Brian Mearns wrote: >> >> On Tue, Apr 13, 2010 at 1:13 PM, Jonathan Zuckerman >> wrote: >> > >> > >> > On Tue, Apr 13, 2010 at 12:13 PM, Brian Mearns >> > wrote: >> >> >> >> On Tue, Apr 13, 2010 at 10:49 AM, Jonathan Zuckerman >> >> wrote: >> >> > On Tue, Apr 13, 2010 at 10:34 AM, Brian Mearns >> >> > wrote: >> >> >> >> >> >> I'd like to use stronger and correlated ETag, namely the hash of t= he >> >> >> content being served. Obviously it's a drag to do this in-line, so >> >> >> I'm >> >> >> planning an automated task to generate the ETag values and store >> >> >> them >> >> >> on the server. Is there any way I can get httpd to grab these stor= ed >> >> >> values for use in the Etag header? I'm flexible on how I store the= m: >> >> >> in a database, in one large file, each in its own file named >> >> >> according >> >> >> to the resource, etc. >> >> >> >> >> >> Any ideas? >> >> >> >> >> >> Thanks, >> >> >> -Brian >> >> >> >> >> >> -- >> >> >> Feel free to contact me using PGP Encryption: >> >> >> Key Id: 0x3AA70848 >> >> >> Available from: http://keys.gnupg.net >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------= --- >> >> >> The official User-To-User support forum of the Apache HTTP Server >> >> >> Project. >> >> >> See for more info. >> >> >> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org >> >> >> =A0 " =A0 from the digest: users-digest-unsubscribe@httpd.apache.o= rg >> >> >> For additional commands, e-mail: users-help@httpd.apache.org >> >> >> >> >> > >> >> > I have some "static" content that's actually built dynamically on t= he >> >> > server >> >> > (it's just a concatenated, minified JS or CSS file), and therefore >> >> > can't >> >> > use >> >> > Apache's default etags/expires headers which I believe only apply t= o >> >> > real >> >> > files, so I do the same thing you're suggesting, in php. >> >> > I would much rather let Apache take care of this for me, but my >> >> > obsessive >> >> > and orderly mind demands that I keep the Javascript and CSS that >> >> > applies >> >> > to >> >> > different parts of the site in different files, and my background i= n >> >> > high-load high-availability web-serving makes me want to keep the >> >> > number >> >> > of >> >> > http requests down. >> >> > So my question to you is, what is your reason for wanting to do thi= s, >> >> > and >> >> > how would you implement if it did exist? =A0It's pretty trivial to = do >> >> > it >> >> > with >> >> > a scripting language that can alter response headers, if in fact it= 's >> >> > really >> >> > necessary.. >> >> >> >> The reason is just to optimize caching. I guess the ETag doesn't >> >> really need to be any stronger than the built-in, but I would like it >> >> to be correlated, meaning if the content hasn't actually changed, or >> >> has changed and then changed back, it will have the same ETag even >> >> though the last-mod time is different. >> >> >> >> I'm not sure exactly what you mean by how I would implement it. In >> >> terms of generating the ETag values? For true static content, I would >> >> just hash the file. For PHP, for instance, I would filter it through >> >> `php -w` first, and hash the result. Like I said, I'm not sure exactl= y >> >> how I will store the generated values, it depends on how I'm actually >> >> getting the values in the headers. I would use either a cron job or a >> >> publishing-script to update the stored ETags. >> >> >> >> I have done this before in PHP, but I'd hate to have to serve static >> >> content through a wrapper PHP script just to put an ETag header in >> >> there. >> >> >> >> Thanks, >> >> -Brian >> >> >> >> >> >> -- >> >> Feel free to contact me using PGP Encryption: >> >> Key Id: 0x3AA70848 >> >> Available from: http://keys.gnupg.net >> >> >> >> --------------------------------------------------------------------- >> >> The official User-To-User support forum of the Apache HTTP Server >> >> Project. >> >> See for more info. >> >> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org >> >> =A0 " =A0 from the digest: users-digest-unsubscribe@httpd.apache.org >> >> For additional commands, e-mail: users-help@httpd.apache.org >> >> >> > >> > check out=A0http://httpd.apache.org/docs/2.0/mod/core.html#fileetag >> > If you can't get what you want with that, my personal opinion is that >> > the >> > performance gained by your request would not justify the amount of tim= e >> > required to develop it. >> >> Thanks for the reference. The FileEtag directive is not as strong as >> what I'm looking for. I understand your sentiment about it not being >> worth the effort: but development effort is temporary, performance >> improvements are forever =3D). >> >> -Brian >> >> -- >> Feel free to contact me using PGP Encryption: >> Key Id: 0x3AA70848 >> Available from: http://keys.gnupg.net >> >> --------------------------------------------------------------------- >> The official User-To-User support forum of the Apache HTTP Server Projec= t. >> See for more info. >> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org >> =A0 " =A0 from the digest: users-digest-unsubscribe@httpd.apache.org >> For additional commands, e-mail: users-help@httpd.apache.org >> > > Of course performance is everything. > Every time a user requests a resource, this is what you want in your > proposed scenario: > calculate hash of file based on _file contents_ -> compare it to the user= 's > declared e-tag -> send either 200 or 304 response > this is what's currently happening: > calculate hash of file based on _file attributes_ -> compare it to user's > e-tag/expires data -> send response > It seems to me that right off the bat you're losing performance because i= t > will certainly take longer to pull the full contents of the file and hash > that, rather than just using the attributes of the file to compute the > e-tag. > The only scenario in which your method performs better than the standard > Apache e-tag implementation is when a file is modified and later restored= to > its original state between the time the user accesses that resource a fir= st > and second time. =A0If I was an engineer in your group I'd ask to see som= e > data to prove this happens often enough to make up for the initial > performance loss. > Does that make sense, am I missing any details or anything? A small but important detail: I'm hashing the content off-line, so my proposed process looks like this (when a request comes in): read tag from file/database/etc -> compare to submitted etag -> send respon= se. So yes, it will be primarily of benefit when the content changes and changes back, but it should (in theory) always be a bit faster than the default, since there are no attributes to check and no hash to perform as far as apache is concerned. This is a personal web server, there's no group or any other bureaucracy for me to worry about =3D). I'm fine-tuning it as a hobby. -Brian --=20 Feel free to contact me using PGP Encryption: Key Id: 0x3AA70848 Available from: http://keys.gnupg.net --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See for more info. To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org " from the digest: users-digest-unsubscribe@httpd.apache.org For additional commands, e-mail: users-help@httpd.apache.org