From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Hartwig Newsgroups: gmane.lisp.guile.bugs,gmane.lisp.guile.user Subject: bug#10147: HTTP "Expires" header should handle non-date values Date: Thu, 22 Dec 2011 12:28:01 +0800 Message-ID: References: <87ty4tqpyf.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1324528146 10837 80.91.229.12 (22 Dec 2011 04:29:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Dec 2011 04:29:06 +0000 (UTC) Cc: "R. P. Dillon" , guile-user@gnu.org, 10147@debbugs.gnu.org To: Andy Wingo Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Thu Dec 22 05:29:01 2011 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RdaH6-00077N-16 for guile-bugs@m.gmane.org; Thu, 22 Dec 2011 05:29:00 +0100 Original-Received: from localhost ([::1]:47924 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdaH5-00050k-61 for guile-bugs@m.gmane.org; Wed, 21 Dec 2011 23:28:59 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:43447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdaH2-00050U-NT for bug-guile@gnu.org; Wed, 21 Dec 2011 23:28:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RdaH1-0002gG-Bo for bug-guile@gnu.org; Wed, 21 Dec 2011 23:28:56 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdaH1-0002gB-8i for bug-guile@gnu.org; Wed, 21 Dec 2011 23:28:55 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RdaJ4-0003Os-DO for bug-guile@gnu.org; Wed, 21 Dec 2011 23:31:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Hartwig Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Thu, 22 Dec 2011 04:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10147 X-GNU-PR-Package: guile X-GNU-PR-Keywords: patch Original-Received: via spool by 10147-submit@debbugs.gnu.org id=B10147.132452821313012 (code B ref 10147); Thu, 22 Dec 2011 04:31:02 +0000 Original-Received: (at 10147) by debbugs.gnu.org; 22 Dec 2011 04:30:13 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RdaIH-0003Np-5t for submit@debbugs.gnu.org; Wed, 21 Dec 2011 23:30:13 -0500 Original-Received: from mail-iy0-f172.google.com ([209.85.210.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RdaIE-0003Nh-04 for 10147@debbugs.gnu.org; Wed, 21 Dec 2011 23:30:11 -0500 Original-Received: by iaen33 with SMTP id n33so4318744iae.3 for <10147@debbugs.gnu.org>; Wed, 21 Dec 2011 20:28:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0WisBw9kDXlSpCdQ+n1u6AF1NrCm7Pz/vBku52+jyeQ=; b=HoNjgEGpxGjypBu6ls2laVRGfWdYRnP/bS1RwBn7WSG17u+BKLsBo09vnWSe6OukrW /Fgo0wbjYvcpKlLbDRpBA1VP6rx7/jYJVYM52XI4EZnD6wZKpmjj7mwBDGIx/qCaBc2K Xn3bOEftomnZw8ZvC09VRuqQhcsgLtE3MUf8o= Original-Received: by 10.50.157.229 with SMTP id wp5mr6923935igb.22.1324528081789; Wed, 21 Dec 2011 20:28:01 -0800 (PST) Original-Received: by 10.231.219.134 with HTTP; Wed, 21 Dec 2011 20:28:01 -0800 (PST) In-Reply-To: <87ty4tqpyf.fsf@pobox.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 21 Dec 2011 23:31:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:6006 gmane.lisp.guile.user:9068 Archived-At: On 22 December 2011 10:51, Andy Wingo wrote: > > On Sun 27 Nov 2011 05:39, Daniel Hartwig writes: > >> This is definitely a bug on Guile's part, HTTP/1.1 permits such values >> for "Expires" headers [1], treating them as though they were a date in >> the past: >> >> =A0 =A0HTTP/1.1 clients and caches MUST treat other invalid date formats= , >> =A0 =A0especially including the value "0", as in the past (i.e., "alread= y >> =A0 =A0expired"). >> >> [1] http://tools.ietf.org/html/rfc2616#section-14.21 > > But that's right after saying > > =A0 The format is an absolute date and time as defined by HTTP-date in > =A0 section 3.3.1; it MUST be in RFC 1123 date format: > > =A0 =A0 =A0Expires =3D "Expires" ":" HTTP-date > > But, pragmatism may rule, here... > ... especially given that players like Google are using "-1" ;-) > ... Wouldn't it > be better to keep the expires header as a date? =A0Would any date in the > past work fine? > That is what I initially considered. A great solution because it requires no changes to existing code which would be expecting a date value. I think any date would do, ideally it would match the value of the Date header, but the current parsing code does not allow for access to it. I considered using a single, well defined value for date-in-the-past (Unix epoch). The *only* concern I had with this approach is wrt implementing a cache/proxy. My idea was that by storing the non-date values as a string you can store/forward these unmodified and still check for the "already expired" condition. Admitedly this is a very minor concern, as there is no change in semantics at the protocol level -- both approaches result in the client understanding that the content is already expired. I think what I came up with was a solution in need of a problem (which should be solved more generally across the whole module any way). > Would it be best to allow some special cases like "0" or "-1" instead? > Not sure precisely what you mean here. Is it something like: (or (false-if-exception (parse-date str)) (and (memq str '("0" "-1")) str) date-in-the-past) ? > I'm just trying to limit the damage here :) =A0WDYT? > I am certainly in favour of keeping the value as a date to achieve this aim.