From unknown Sat Aug 09 05:03:47 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10147: HTTP "Expires" header should handle non-date values Resent-From: Daniel Hartwig Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Sun, 27 Nov 2011 10:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 10147 X-GNU-PR-Package: guile X-GNU-PR-Keywords: patch To: "R. P. Dillon" Cc: 10147@debbugs.gnu.org, guile-user@gnu.org X-Debbugs-Original-Cc: bug-guile@gnu.org, guile-user@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.132239047522058 (code B ref -1); Sun, 27 Nov 2011 10:42:02 +0000 Received: (at submit) by debbugs.gnu.org; 27 Nov 2011 10:41:15 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RUcAd-0005jj-2I for submit@debbugs.gnu.org; Sun, 27 Nov 2011 05:41:15 -0500 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RUcAa-0005jU-CO for submit@debbugs.gnu.org; Sun, 27 Nov 2011 05:41:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUc8p-0004gR-6m for submit@debbugs.gnu.org; Sun, 27 Nov 2011 05:39:24 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:48853) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUc8p-0004gM-5F for submit@debbugs.gnu.org; Sun, 27 Nov 2011 05:39:23 -0500 Received: from eggs.gnu.org ([140.186.70.92]:42032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUc8m-0007we-5h for bug-guile@gnu.org; Sun, 27 Nov 2011 05:39:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUc8k-0004f6-Qd for bug-guile@gnu.org; Sun, 27 Nov 2011 05:39:20 -0500 Received: from mail-iy0-f169.google.com ([209.85.210.169]:57614) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUc8g-0004eK-8Y; Sun, 27 Nov 2011 05:39:14 -0500 Received: by iaek3 with SMTP id k3so9194379iae.0 for ; Sun, 27 Nov 2011 02:39:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=oMfqY5nbsimbeZ/DIGq77edRK+eEtVY8l3MuUIwzYPc=; b=aRFAn1zcM/fW+LDxL3dlgPFcez5TT0cTq0Z8OUKbMMMqpdRAm2hq/JmdLEtRmoy2Wf eAJmhPv3KINRs5tknkx2jAvF46s+baO9q+lxYuh1FRkiBtsxAMJ2sOWpbm2PXLiwCSjP 5aIKdvA2IFlwGFdIEKKX6oo170MIJbw7Q8mfg= MIME-Version: 1.0 Received: by 10.42.131.135 with SMTP id z7mr1230848ics.23.1322390352870; Sun, 27 Nov 2011 02:39:12 -0800 (PST) Received: by 10.231.206.138 with HTTP; Sun, 27 Nov 2011 02:39:12 -0800 (PST) Date: Sun, 27 Nov 2011 18:39:12 +0800 Message-ID: From: Daniel Hartwig Content-Type: multipart/mixed; boundary=90e6ba1efba83cbb6204b2b4ff0a X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.8 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.1 (-----) --90e6ba1efba83cbb6204b2b4ff0a Content-Type: text/plain; charset=ISO-8859-1 Package: guile Version: 2.0.3 Tags: patch On 6 November 2011 13:49, R. P. Dillon wrote: > (use-modules (web request) (web response) (web uri) (rnrs bytevectors)) > (define port (socket PF_INET SOCK_STREAM 0)) > (define address (addrinfo:addr (car (getaddrinfo "www.google.com" "http")))) > (connect port address) > (define request (build-request (build-uri 'http #:host "www.google.com"))) > (write-request request port) > (define response (read-response port)) > (read-response ...) consistently fails with Google: > web/http.scm:754:6: In procedure parse-asctime-date: > web/http.scm:754:6: Throw to key `bad-header' with args `(date "-1")'. > The expiration is set to -1 in the headers, and this seems to cause a > problem for the web libraries in Guile. > This same request seems to work well for my own domain (killring.org). 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: HTTP/1.1 clients and caches MUST treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired"). [1] http://tools.ietf.org/html/rfc2616#section-14.21 Attached patch permits non-date values for "Expires", leaving them as strings (preferable, as such responses can be transparently forwarded to other clients). The staleness of a response could be determined quite crudely, e.g. (define (response-stale? r) (let ((expires (response-expires r))) (and expires (or (not (date? expires)) ;; Indicates already expired. (time<=? (date->time-utc expires) (current-time)))))) This approach completely ignores the recommended way of determining whether a response has expired. See section 13.2.4 of the RFC for calculations involving various factors such as the time that a request was sent, "Cache-Control" directives, etc. Regards Daniel --90e6ba1efba83cbb6204b2b4ff0a Content-Type: text/x-patch; charset=US-ASCII; name="0001-Permit-non-date-values-for-Expires-header.patch" Content-Disposition: attachment; filename="0001-Permit-non-date-values-for-Expires-header.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gvhx247v0 RnJvbSBkY2JjZDk0ZGI4OWE4ZTczZWJjMzA4OWE4NjA1NzViYmViOGQxNzA4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBEYW5pZWwgSGFydHdpZyA8bWFuZHlrZUBnbWFpbC5jb20+CkRh dGU6IFN1biwgMjcgTm92IDIwMTEgMTg6MjU6NTUgKzA4MDAKU3ViamVjdDogW1BBVENIXSBQZXJt aXQgbm9uLWRhdGUgdmFsdWVzIGZvciAiRXhwaXJlcyIgaGVhZGVyLgoKKiBtb2R1bGUvd2ViL2h0 dHAuc2NtICgiRXhwaXJlcyIpOiBQZXJtaXQgbm9uLWRhdGUgdmFsdWVzLgotLS0KIG1vZHVsZS93 ZWIvaHR0cC5zY20gICAgICAgICAgICB8ICAgMjAgKysrKysrKysrKysrKysrKysrKy0KIHRlc3Qt c3VpdGUvdGVzdHMvd2ViLWh0dHAudGVzdCB8ICAgIDEgKwogMiBmaWxlcyBjaGFuZ2VkLCAyMCBp bnNlcnRpb25zKCspLCAxIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL21vZHVsZS93ZWIvaHR0 cC5zY20gYi9tb2R1bGUvd2ViL2h0dHAuc2NtCmluZGV4IGRjNzQyYTEuLjVlYjJlOTAgMTAwNjQ0 Ci0tLSBhL21vZHVsZS93ZWIvaHR0cC5zY20KKysrIGIvbW9kdWxlL3dlYi9odHRwLnNjbQpAQCAt MTUwMCw3ICsxNTAwLDI1IEBAIHBocmFzZVwiLiIKIAogOzsgRXhwaXJlcyA9IEhUVFAtZGF0ZQog OzsKLShkZWNsYXJlLWRhdGUtaGVhZGVyISAiRXhwaXJlcyIpCis7OyAuLi4KKzs7IEhUVFAvMS4x IGNsaWVudHMgYW5kIGNhY2hlcyBNVVNUIHRyZWF0IG90aGVyIGludmFsaWQgZGF0ZSBmb3JtYXRz LAorOzsgZXNwZWNpYWxseSBpbmNsdWRpbmcgdGhlIHZhbHVlICIwIiwgYXMgaW4gdGhlIHBhc3Qg KGkuZS4sICJhbHJlYWR5Cis7OyBleHBpcmVkIikuCis7OworKGRlY2xhcmUtaGVhZGVyISAiRXhw aXJlcyIKKyAgKGxhbWJkYSAoc3RyKQorICAgIChvciAoZmFsc2UtaWYtZXhjZXB0aW9uIChwYXJz ZS1kYXRlIHN0cikpCisgICAgICAgIHN0cikpCisgIChsYW1iZGEgKHZhbCkKKyAgICAob3IgKHN0 cmluZz8gdmFsKSAoZGF0ZT8gdmFsKSkpCisgIChsYW1iZGEgKHZhbCBwb3J0KQorICAgIChjb25k CisgICAgICgoc3RyaW5nPyB2YWwpCisgICAgICAoZGlzcGxheSB2YWwgcG9ydCkpCisgICAgICgo ZGF0ZT8gdmFsKQorICAgICAgKHdyaXRlLWRhdGUgdmFsIHBvcnQpKQorICAgICAoZWxzZQorICAg ICAgKGJhZC1oZWFkZXItY29tcG9uZW50ICdleHBpcmVzIHZhbCkpKSkpCiAKIDs7IExhc3QtTW9k aWZpZWQgPSBIVFRQLWRhdGUKIDs7CmRpZmYgLS1naXQgYS90ZXN0LXN1aXRlL3Rlc3RzL3dlYi1o dHRwLnRlc3QgYi90ZXN0LXN1aXRlL3Rlc3RzL3dlYi1odHRwLnRlc3QKaW5kZXggYjZhYmJmMy4u Yzg4MTIyMyAxMDA2NDQKLS0tIGEvdGVzdC1zdWl0ZS90ZXN0cy93ZWItaHR0cC50ZXN0CisrKyBi L3Rlc3Qtc3VpdGUvdGVzdHMvd2ViLWh0dHAudGVzdApAQCAtMTM0LDYgKzEzNCw3IEBACiAgIChw YXNzLWlmLXBhcnNlIGV4cGlyZXMgIlR1ZSwgMTUgTm92IDE5OTQgMDg6MTI6MzEgR01UIgogICAg ICAgICAgICAgICAgICAoc3RyaW5nLT5kYXRlICJUdWUsIDE1IE5vdiAxOTk0IDA4OjEyOjMxICsw MDAwIgogICAgICAgICAgICAgICAgICAgICAgICAgICJ+YSwgfmQgfmIgflkgfkg6fk06flMgfnoi KSkKKyAgKHBhc3MtaWYtcGFyc2UgZXhwaXJlcyAiMCIgIjAiKQogICAocGFzcy1pZi1wYXJzZSBs YXN0LW1vZGlmaWVkICJUdWUsIDE1IE5vdiAxOTk0IDA4OjEyOjMxIEdNVCIKICAgICAgICAgICAg ICAgICAgKHN0cmluZy0+ZGF0ZSAiVHVlLCAxNSBOb3YgMTk5NCAwODoxMjozMSArMDAwMCIKICAg ICAgICAgICAgICAgICAgICAgICAgICAifmEsIH5kIH5iIH5ZIH5IOn5NOn5TIH56IikpKQotLSAK MS43LjIuNQoK --90e6ba1efba83cbb6204b2b4ff0a-- From unknown Sat Aug 09 05:03:47 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10147: HTTP "Expires" header should handle non-date values Resent-From: Andy Wingo Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Thu, 22 Dec 2011 02:54:01 +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 To: Daniel Hartwig Cc: "R. P. Dillon" , guile-user@gnu.org, 10147@debbugs.gnu.org Received: via spool by 10147-submit@debbugs.gnu.org id=B10147.13245224004641 (code B ref 10147); Thu, 22 Dec 2011 02:54:01 +0000 Received: (at 10147) by debbugs.gnu.org; 22 Dec 2011 02:53:20 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RdYmV-0001Co-Sy for submit@debbugs.gnu.org; Wed, 21 Dec 2011 21:53:20 -0500 Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62] helo=sasl.smtp.pobox.com) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RdYmS-0001Ce-DY for 10147@debbugs.gnu.org; Wed, 21 Dec 2011 21:53:18 -0500 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 753D58F9A; Wed, 21 Dec 2011 21:51:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=w/nGN8Bv4OpOyF/0YGcDFRmlfzY=; b=Y4mYDQ ZLcJ0yU5bSpkpcRvX4R6ZxqGhdNiBgzK0tcN7/aym8G2L+PxCRNt0WhT7xLT4Pc5 8NFGiYx7aCD6u6XdJzeNUymbxSqwiPWJDoFC87Fw3Ra0KWnDUfYuYnqfnq18XQim VxcrZbjHqXEKAidDjM/h89Am9qsrZZTR+Ntrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=imKpnEG3VI/6i+2q9OZxSWXRrVQ8OoNf McCdsKi009kh/fdTQvxWVslBL0yhb2mjZxbyI7yI+snbn3FrJDKz6C33kInb8B+/ JADUFPLLzuBlC7LgnlgNdRwf151kBIAgUfNP0ewTpVHofu+0ygCHRQwbWwtX5RpP sP1VyrgN2vU= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 456EE8F97; Wed, 21 Dec 2011 21:51:08 -0500 (EST) Received: from badger (unknown [184.174.165.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 4BB9E8F94; Wed, 21 Dec 2011 21:51:07 -0500 (EST) From: Andy Wingo References: Date: Wed, 21 Dec 2011 21:51:04 -0500 In-Reply-To: (Daniel Hartwig's message of "Sun, 27 Nov 2011 18:39:12 +0800") Message-ID: <87ty4tqpyf.fsf@pobox.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Pobox-Relay-ID: CBED2E4E-2C47-11E1-9A2B-65B1DE995924-02397024!a-pb-sasl-sd.pobox.com X-Spam-Score: -2.9 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) Hi Daniel, So sorry for the delay. 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: > > HTTP/1.1 clients and caches MUST treat other invalid date formats, > especially including the value "0", as in the past (i.e., "already > expired"). > > [1] http://tools.ietf.org/html/rfc2616#section-14.21 But that's right after saying The format is an absolute date and time as defined by HTTP-date in section 3.3.1; it MUST be in RFC 1123 date format: Expires = "Expires" ":" HTTP-date But, pragmatism may rule, here... > Attached patch permits non-date values for "Expires", leaving them as > strings (preferable, as such responses can be transparently forwarded > to other clients). The staleness of a response could be determined > quite crudely, e.g. > > (define (response-stale? r) > (let ((expires (response-expires r))) > (and expires > (or (not (date? expires)) ;; Indicates already expired. > (time<=? (date->time-utc expires) > (current-time)))))) Let us assume that it is a good idea to include this hack. Wouldn't it be better to keep the expires header as a date? Would any date in the past work fine? Would it be best to allow some special cases like "0" or "-1" instead? I'm just trying to limit the damage here :) WDYT? Andy -- http://wingolog.org/ From unknown Sat Aug 09 05:03:47 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10147: HTTP "Expires" header should handle non-date values 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 To: Andy Wingo Cc: "R. P. Dillon" , guile-user@gnu.org, 10147@debbugs.gnu.org Received: via spool by 10147-submit@debbugs.gnu.org id=B10147.132452821313012 (code B ref 10147); Thu, 22 Dec 2011 04:31:02 +0000 Received: (at 10147) by debbugs.gnu.org; 22 Dec 2011 04:30:13 +0000 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 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 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= MIME-Version: 1.0 Received: by 10.50.157.229 with SMTP id wp5mr6923935igb.22.1324528081789; Wed, 21 Dec 2011 20:28:01 -0800 (PST) Received: by 10.231.219.134 with HTTP; Wed, 21 Dec 2011 20:28:01 -0800 (PST) In-Reply-To: <87ty4tqpyf.fsf@pobox.com> References: <87ty4tqpyf.fsf@pobox.com> Date: Thu, 22 Dec 2011 12:28:01 +0800 Message-ID: From: Daniel Hartwig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.9 (---) 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. From unknown Sat Aug 09 05:03:47 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10147: HTTP "Expires" header should handle non-date values Resent-From: Andy Wingo Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Thu, 22 Dec 2011 12:38: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 To: Daniel Hartwig Cc: "R. P. Dillon" , guile-user@gnu.org, 10147@debbugs.gnu.org Received: via spool by 10147-submit@debbugs.gnu.org id=B10147.132455746228843 (code B ref 10147); Thu, 22 Dec 2011 12:38:02 +0000 Received: (at 10147) by debbugs.gnu.org; 22 Dec 2011 12:37:42 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rdhu0-0007V9-Me for submit@debbugs.gnu.org; Thu, 22 Dec 2011 07:37:41 -0500 Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62] helo=sasl.smtp.pobox.com) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rdhtx-0007V0-LE for 10147@debbugs.gnu.org; Thu, 22 Dec 2011 07:37:38 -0500 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 6B4DA7E8E; Thu, 22 Dec 2011 07:35:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=sasl; bh=xNW/qF10Y0Ty 9+jvgm3+btTHU7g=; b=KUc906r26DU09RzsPDLdNaHf9AUPi8y1wDjbazCwnjsR xnmbndOGR/TLi43E2zr9HdB9NLbqnYhR9MiniJRJYYYR5BnUxleD4l+KgYkFWXAm CT6rnOs7cJEIlAPQwEjCODJW3mTE0vXJxjFYxW0PJ61nx7qumAQrmkM15L8oa+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=Vxfful y+OMXGSUVQXsqUaEtcI+LxtEWJECWd7ELhPn1bHTs/B6TAdDPIZCij2ABVRKZfYj p5Nd1giatQvonvJQRGASpTexiE+G5dkJ+Xxqw/w7W9zxgpLTMd4VgIqDMpq8udQt E0qA1unaErEafhv+6B3BF7vYJSkfyIk08w5m4= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 64E347E8D; Thu, 22 Dec 2011 07:35:27 -0500 (EST) Received: from badger (unknown [184.174.165.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 148577E8C; Thu, 22 Dec 2011 07:35:27 -0500 (EST) From: Andy Wingo References: <87ty4tqpyf.fsf@pobox.com> Date: Thu, 22 Dec 2011 07:35:24 -0500 In-Reply-To: (Daniel Hartwig's message of "Thu, 22 Dec 2011 12:28:01 +0800") Message-ID: <87hb0srdgz.fsf@pobox.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: 6D2E3A5E-2C99-11E1-ADF9-65B1DE995924-02397024!a-pb-sasl-sd.pobox.com X-Spam-Score: -2.8 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) On Wed 21 Dec 2011 23:28, Daniel Hartwig writes: > On 22 December 2011 10:51, Andy Wingo wrote: >> >> On Sun 27 Nov 2011 05:39, Daniel Hartwig writes: >> >>> =C2=A0 =C2=A0HTTP/1.1 clients and caches MUST treat other invalid date = formats, >>> =C2=A0 =C2=A0especially including the value "0", as in the past (i.e., = "already >>> =C2=A0 =C2=A0expired"). >> >> But, pragmatism may rule, here... > > ... especially given that players like Google are using "-1" ;-) Yes, indeed. >> ... Wouldn't it >> be better to keep the expires header as a date? =C2=A0Would any date in = the >> past work fine? > > That is what I initially considered. I considered using a single, > well defined value for date-in-the-past (Unix epoch). I think I would prefer this. It makes user code easier, and with more of a chance of being correct. I think that Mozilla at least used to use the beginnning of the epoch as this date. >> 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) More like: (if (member str '("0" "-1")) date-in-the-past (parse-date str)) Then we can wait and see -- if only these two values are out there, then we are good, and we keep the "validating" characteristic of our date parser. Otherwise we can fall back to the false-if-exception dance if someone submits a bug report. WDYT? Want to send another patch? :-) Andy --=20 http://wingolog.org/ From unknown Sat Aug 09 05:03:47 2025 X-Loop: help-debbugs@gnu.org Subject: bug#10147: HTTP "Expires" header should handle non-date values Resent-From: Daniel Hartwig Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Tue, 27 Dec 2011 15:52:01 +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 To: Andy Wingo Cc: guile-user@gnu.org, 10147@debbugs.gnu.org Received: via spool by 10147-submit@debbugs.gnu.org id=B10147.132500110225676 (code B ref 10147); Tue, 27 Dec 2011 15:52:01 +0000 Received: (at 10147) by debbugs.gnu.org; 27 Dec 2011 15:51:42 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RfZJV-0006g5-Tv for submit@debbugs.gnu.org; Tue, 27 Dec 2011 10:51:42 -0500 Received: from mail-gx0-f172.google.com ([209.85.161.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RfZJU-0006fy-DQ for 10147@debbugs.gnu.org; Tue, 27 Dec 2011 10:51:41 -0500 Received: by ggnk5 with SMTP id k5so7486864ggn.3 for <10147@debbugs.gnu.org>; Tue, 27 Dec 2011 07:49:00 -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; bh=lW8YtKrO9WqhKN0/V2e079DEQ2C4E9xlCVoNe8duqZw=; b=AYrViHFWo2HW+CYzPjkIexhQwRDmCmAmnCe6gU7TZhilk4a04X5+n1ydHa655YMkgr 8yrsigNV7A6oiJ6NSZAc9cWpOtOlXC4yQ4lWPtX+3fnyglfqHg+JVU4exEm3Cn73vT67 QNhC8cPXs+uBHFlZ9r2iI2jFMuKwxtQ/L4SiI= MIME-Version: 1.0 Received: by 10.50.156.138 with SMTP id we10mr11629777igb.10.1325000940713; Tue, 27 Dec 2011 07:49:00 -0800 (PST) Received: by 10.231.48.68 with HTTP; Tue, 27 Dec 2011 07:49:00 -0800 (PST) In-Reply-To: <87hb0srdgz.fsf@pobox.com> References: <87ty4tqpyf.fsf@pobox.com> <87hb0srdgz.fsf@pobox.com> Date: Tue, 27 Dec 2011 23:49:00 +0800 Message-ID: From: Daniel Hartwig Content-Type: multipart/mixed; boundary=e89a8f234aad65f89104b514d2af X-Spam-Score: -3.9 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.9 (---) --e89a8f234aad65f89104b514d2af Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 22 December 2011 20:35, Andy Wingo wrote: >> Not sure precisely what you mean here. =A0Is it something like: >> >> (or (false-if-exception (parse-date str)) >> =A0 =A0 (and (memq str '("0" "-1")) str) >> =A0 =A0 date-in-the-past) > > More like: > > =A0(if (member str '("0" "-1")) > =A0 =A0 =A0date-in-the-past > =A0 =A0 =A0(parse-date str)) > > Then we can wait and see -- if only these two values are out there, then > we are good, and we keep the "validating" characteristic of our date > parser. =A0Otherwise we can fall back to the false-if-exception dance if > someone submits a bug report. A rough check against ~2600 sites scraped from dmoz.org shows only a handful with other values. These two: "Mon, 12 Jul 1996 1:00:00 GMT" ^ misses leading `0' "Thu, 01 Jan 1970 00:00:00 +0000" ^ should be `GMT' The second (use of `+0000') was also encountered amongst other date-valued headers in ~1% of pages sampled. There might be a case here for relaxing `parse-date' as I don't think these should be handled specifically for "Expires" headers. There were three more like: "{ts '2011-12-27 08:12:22'}" which only appeared for "Expires" headers. They look something like server directives which should have been transformed to legit expiration dates but haven't been, due to misconfiguration. In this case I'd rather throw an error than parse it (wrongly) to date-in-the-past. Given those points, I have attached a patch implementing the suggested handling for "Expires" and will take a look at perhaps relaxing parse-date (and others). Anyone have ideas on that? Daniel --e89a8f234aad65f89104b514d2af Content-Type: text/x-patch; charset=US-ASCII; name="0001-permit-non-date-values-for-Expires-header.patch" Content-Disposition: attachment; filename="0001-permit-non-date-values-for-Expires-header.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gwp37ai00 RnJvbSA4YjdlZGEwYmQ3YjAzNDY3ZjZlZWYwY2U2Yzk5ZGVkZjhmZDNhYzBjIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBEYW5pZWwgSGFydHdpZyA8bWFuZHlrZUBnbWFpbC5jb20+CkRh dGU6IFR1ZSwgMjcgRGVjIDIwMTEgMjI6MjQ6MjggKzA4MDAKU3ViamVjdDogW1BBVENIXSBwZXJt aXQgbm9uLWRhdGUgdmFsdWVzIGZvciBFeHBpcmVzIGhlYWRlcgoKKiBtb2R1bGUvd2ViL2h0dHAu c2NtICgiRXhwaXJlcyIpOiBQZXJtaXQgKHNvbWUpIG5vbi1kYXRlIHZhbHVlcy4KLS0tCiBtb2R1 bGUvd2ViL2h0dHAuc2NtIHwgICAxMCArKysrKysrKystCiAxIGZpbGVzIGNoYW5nZWQsIDkgaW5z ZXJ0aW9ucygrKSwgMSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9tb2R1bGUvd2ViL2h0dHAu c2NtIGIvbW9kdWxlL3dlYi9odHRwLnNjbQppbmRleCBhZmU3MGE3Li45YmI0NDQ5IDEwMDY0NAot LS0gYS9tb2R1bGUvd2ViL2h0dHAuc2NtCisrKyBiL21vZHVsZS93ZWIvaHR0cC5zY20KQEAgLTE1 MDYsNyArMTUwNiwxNSBAQCBwaHJhc2VcIi4iCiAKIDs7IEV4cGlyZXMgPSBIVFRQLWRhdGUKIDs7 Ci0oZGVjbGFyZS1kYXRlLWhlYWRlciEgIkV4cGlyZXMiKQorKGRlZmluZSAqZGF0ZS1pbi10aGUt cGFzdCogKHBhcnNlLWRhdGUgIlRodSwgMDEgSmFuIDE5NzAgMDA6MDA6MDAgR01UIikpCisKKyhk ZWNsYXJlLWhlYWRlciEgIkV4cGlyZXMiCisgIChsYW1iZGEgKHN0cikKKyAgICAoaWYgKG1lbWJl ciBzdHIgJygiMCIgIi0xIikpCisgICAgICAgICpkYXRlLWluLXRoZS1wYXN0KgorICAgICAgICAo cGFyc2UtZGF0ZSBzdHIpKSkKKyAgZGF0ZT8KKyAgd3JpdGUtZGF0ZSkKIAogOzsgTGFzdC1Nb2Rp ZmllZCA9IEhUVFAtZGF0ZQogOzsKLS0gCjEuNy41LjQKCg== --e89a8f234aad65f89104b514d2af-- From unknown Sat Aug 09 05:03:47 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Daniel Hartwig Subject: bug#10147: closed (Re: bug#10147: HTTP "Expires" header should handle non-date values) Message-ID: References: <87mx9w4i6b.fsf@pobox.com> X-Gnu-PR-Message: they-closed 10147 X-Gnu-PR-Package: guile X-Gnu-PR-Keywords: patch Reply-To: 10147@debbugs.gnu.org Date: Mon, 09 Jan 2012 22:38:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1326148683-16414-1" This is a multi-part message in MIME format... ------------=_1326148683-16414-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #10147: HTTP "Expires" header should handle non-date values which was filed against the guile package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 10147@debbugs.gnu.org. --=20 10147: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D10147 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1326148683-16414-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 10147-done) by debbugs.gnu.org; 9 Jan 2012 22:37:14 +0000 Received: from localhost ([127.0.0.1]:51419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RkNq5-0004Fb-SL for submit@debbugs.gnu.org; Mon, 09 Jan 2012 17:37:14 -0500 Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:57326 helo=sasl.smtp.pobox.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RkNpx-0004FD-P2 for 10147-done@debbugs.gnu.org; Mon, 09 Jan 2012 17:37:11 -0500 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 7C7418366; Mon, 9 Jan 2012 17:36:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=5EQYL24Qo021N/HRQgL6NoAjGVk=; b=nIISBa 7j0lYdk2ajHBJZAodwX+ExT5msYxxEfl9fyqrBx6MdDwfzhXcGks60nCe3CdxZp0 mWurrfM5uKgrXC4mCikPHCvEl+53IXiDVYs2QSvNlHVBw2h/gM2rJxiY8t80NW9k 8HuI5YujDJTKIZwbqZfEPIojOdHsBYpDxMqtA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=Xp2lW3IfO+uMqadXwXdAxCcyBLxu61zc lZftgPq3FY80Vc0Ct3fGayKwPZ65Un9YBiQgTfQCUCHrHJoyYOOM/wWMV7Pn4Hps 9s90m31pKAVDHfG6p3/P1pvFINtuznchLTdwq0aN/hrX5iyJylu1MR7WEOdOkpTP rNfFgyiT1R0= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 741AA8365; Mon, 9 Jan 2012 17:36:49 -0500 (EST) Received: from badger (unknown [90.164.198.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id D01408360; Mon, 9 Jan 2012 17:36:48 -0500 (EST) From: Andy Wingo To: Daniel Hartwig Subject: Re: bug#10147: HTTP "Expires" header should handle non-date values References: <87ty4tqpyf.fsf@pobox.com> <87hb0srdgz.fsf@pobox.com> Date: Mon, 09 Jan 2012 23:36:44 +0100 In-Reply-To: (Daniel Hartwig's message of "Tue, 27 Dec 2011 23:49:00 +0800") Message-ID: <87mx9w4i6b.fsf@pobox.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Pobox-Relay-ID: 6B182694-3B12-11E1-8DC6-65B1DE995924-02397024!a-pb-sasl-sd.pobox.com X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 10147-done Cc: guile-user@gnu.org, 10147-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Hi Daniel, Thanks very much for the thorough analysis! On Tue 27 Dec 2011 16:49, Daniel Hartwig writes: > Given those points, I have attached a patch implementing the suggested > handling for "Expires" and will take a look at perhaps relaxing > parse-date (and others). Anyone have ideas on that? I applied your patch, and I think some sensible parse-date relaxations are a good idea too. Regards, Andy -- http://wingolog.org/ ------------=_1326148683-16414-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 27 Nov 2011 10:41:15 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RUcAd-0005jj-2I for submit@debbugs.gnu.org; Sun, 27 Nov 2011 05:41:15 -0500 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RUcAa-0005jU-CO for submit@debbugs.gnu.org; Sun, 27 Nov 2011 05:41:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUc8p-0004gR-6m for submit@debbugs.gnu.org; Sun, 27 Nov 2011 05:39:24 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:48853) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUc8p-0004gM-5F for submit@debbugs.gnu.org; Sun, 27 Nov 2011 05:39:23 -0500 Received: from eggs.gnu.org ([140.186.70.92]:42032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUc8m-0007we-5h for bug-guile@gnu.org; Sun, 27 Nov 2011 05:39:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUc8k-0004f6-Qd for bug-guile@gnu.org; Sun, 27 Nov 2011 05:39:20 -0500 Received: from mail-iy0-f169.google.com ([209.85.210.169]:57614) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUc8g-0004eK-8Y; Sun, 27 Nov 2011 05:39:14 -0500 Received: by iaek3 with SMTP id k3so9194379iae.0 for ; Sun, 27 Nov 2011 02:39:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=oMfqY5nbsimbeZ/DIGq77edRK+eEtVY8l3MuUIwzYPc=; b=aRFAn1zcM/fW+LDxL3dlgPFcez5TT0cTq0Z8OUKbMMMqpdRAm2hq/JmdLEtRmoy2Wf eAJmhPv3KINRs5tknkx2jAvF46s+baO9q+lxYuh1FRkiBtsxAMJ2sOWpbm2PXLiwCSjP 5aIKdvA2IFlwGFdIEKKX6oo170MIJbw7Q8mfg= MIME-Version: 1.0 Received: by 10.42.131.135 with SMTP id z7mr1230848ics.23.1322390352870; Sun, 27 Nov 2011 02:39:12 -0800 (PST) Received: by 10.231.206.138 with HTTP; Sun, 27 Nov 2011 02:39:12 -0800 (PST) Date: Sun, 27 Nov 2011 18:39:12 +0800 Message-ID: Subject: HTTP "Expires" header should handle non-date values From: Daniel Hartwig To: "R. P. Dillon" Content-Type: multipart/mixed; boundary=90e6ba1efba83cbb6204b2b4ff0a X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.8 (----) X-Debbugs-Envelope-To: submit Cc: bug-guile@gnu.org, guile-user@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.1 (-----) --90e6ba1efba83cbb6204b2b4ff0a Content-Type: text/plain; charset=ISO-8859-1 Package: guile Version: 2.0.3 Tags: patch On 6 November 2011 13:49, R. P. Dillon wrote: > (use-modules (web request) (web response) (web uri) (rnrs bytevectors)) > (define port (socket PF_INET SOCK_STREAM 0)) > (define address (addrinfo:addr (car (getaddrinfo "www.google.com" "http")))) > (connect port address) > (define request (build-request (build-uri 'http #:host "www.google.com"))) > (write-request request port) > (define response (read-response port)) > (read-response ...) consistently fails with Google: > web/http.scm:754:6: In procedure parse-asctime-date: > web/http.scm:754:6: Throw to key `bad-header' with args `(date "-1")'. > The expiration is set to -1 in the headers, and this seems to cause a > problem for the web libraries in Guile. > This same request seems to work well for my own domain (killring.org). 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: HTTP/1.1 clients and caches MUST treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired"). [1] http://tools.ietf.org/html/rfc2616#section-14.21 Attached patch permits non-date values for "Expires", leaving them as strings (preferable, as such responses can be transparently forwarded to other clients). The staleness of a response could be determined quite crudely, e.g. (define (response-stale? r) (let ((expires (response-expires r))) (and expires (or (not (date? expires)) ;; Indicates already expired. (time<=? (date->time-utc expires) (current-time)))))) This approach completely ignores the recommended way of determining whether a response has expired. See section 13.2.4 of the RFC for calculations involving various factors such as the time that a request was sent, "Cache-Control" directives, etc. Regards Daniel --90e6ba1efba83cbb6204b2b4ff0a Content-Type: text/x-patch; charset=US-ASCII; name="0001-Permit-non-date-values-for-Expires-header.patch" Content-Disposition: attachment; filename="0001-Permit-non-date-values-for-Expires-header.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gvhx247v0 RnJvbSBkY2JjZDk0ZGI4OWE4ZTczZWJjMzA4OWE4NjA1NzViYmViOGQxNzA4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBEYW5pZWwgSGFydHdpZyA8bWFuZHlrZUBnbWFpbC5jb20+CkRh dGU6IFN1biwgMjcgTm92IDIwMTEgMTg6MjU6NTUgKzA4MDAKU3ViamVjdDogW1BBVENIXSBQZXJt aXQgbm9uLWRhdGUgdmFsdWVzIGZvciAiRXhwaXJlcyIgaGVhZGVyLgoKKiBtb2R1bGUvd2ViL2h0 dHAuc2NtICgiRXhwaXJlcyIpOiBQZXJtaXQgbm9uLWRhdGUgdmFsdWVzLgotLS0KIG1vZHVsZS93 ZWIvaHR0cC5zY20gICAgICAgICAgICB8ICAgMjAgKysrKysrKysrKysrKysrKysrKy0KIHRlc3Qt c3VpdGUvdGVzdHMvd2ViLWh0dHAudGVzdCB8ICAgIDEgKwogMiBmaWxlcyBjaGFuZ2VkLCAyMCBp bnNlcnRpb25zKCspLCAxIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL21vZHVsZS93ZWIvaHR0 cC5zY20gYi9tb2R1bGUvd2ViL2h0dHAuc2NtCmluZGV4IGRjNzQyYTEuLjVlYjJlOTAgMTAwNjQ0 Ci0tLSBhL21vZHVsZS93ZWIvaHR0cC5zY20KKysrIGIvbW9kdWxlL3dlYi9odHRwLnNjbQpAQCAt MTUwMCw3ICsxNTAwLDI1IEBAIHBocmFzZVwiLiIKIAogOzsgRXhwaXJlcyA9IEhUVFAtZGF0ZQog OzsKLShkZWNsYXJlLWRhdGUtaGVhZGVyISAiRXhwaXJlcyIpCis7OyAuLi4KKzs7IEhUVFAvMS4x IGNsaWVudHMgYW5kIGNhY2hlcyBNVVNUIHRyZWF0IG90aGVyIGludmFsaWQgZGF0ZSBmb3JtYXRz LAorOzsgZXNwZWNpYWxseSBpbmNsdWRpbmcgdGhlIHZhbHVlICIwIiwgYXMgaW4gdGhlIHBhc3Qg KGkuZS4sICJhbHJlYWR5Cis7OyBleHBpcmVkIikuCis7OworKGRlY2xhcmUtaGVhZGVyISAiRXhw aXJlcyIKKyAgKGxhbWJkYSAoc3RyKQorICAgIChvciAoZmFsc2UtaWYtZXhjZXB0aW9uIChwYXJz ZS1kYXRlIHN0cikpCisgICAgICAgIHN0cikpCisgIChsYW1iZGEgKHZhbCkKKyAgICAob3IgKHN0 cmluZz8gdmFsKSAoZGF0ZT8gdmFsKSkpCisgIChsYW1iZGEgKHZhbCBwb3J0KQorICAgIChjb25k CisgICAgICgoc3RyaW5nPyB2YWwpCisgICAgICAoZGlzcGxheSB2YWwgcG9ydCkpCisgICAgICgo ZGF0ZT8gdmFsKQorICAgICAgKHdyaXRlLWRhdGUgdmFsIHBvcnQpKQorICAgICAoZWxzZQorICAg ICAgKGJhZC1oZWFkZXItY29tcG9uZW50ICdleHBpcmVzIHZhbCkpKSkpCiAKIDs7IExhc3QtTW9k aWZpZWQgPSBIVFRQLWRhdGUKIDs7CmRpZmYgLS1naXQgYS90ZXN0LXN1aXRlL3Rlc3RzL3dlYi1o dHRwLnRlc3QgYi90ZXN0LXN1aXRlL3Rlc3RzL3dlYi1odHRwLnRlc3QKaW5kZXggYjZhYmJmMy4u Yzg4MTIyMyAxMDA2NDQKLS0tIGEvdGVzdC1zdWl0ZS90ZXN0cy93ZWItaHR0cC50ZXN0CisrKyBi L3Rlc3Qtc3VpdGUvdGVzdHMvd2ViLWh0dHAudGVzdApAQCAtMTM0LDYgKzEzNCw3IEBACiAgIChw YXNzLWlmLXBhcnNlIGV4cGlyZXMgIlR1ZSwgMTUgTm92IDE5OTQgMDg6MTI6MzEgR01UIgogICAg ICAgICAgICAgICAgICAoc3RyaW5nLT5kYXRlICJUdWUsIDE1IE5vdiAxOTk0IDA4OjEyOjMxICsw MDAwIgogICAgICAgICAgICAgICAgICAgICAgICAgICJ+YSwgfmQgfmIgflkgfkg6fk06flMgfnoi KSkKKyAgKHBhc3MtaWYtcGFyc2UgZXhwaXJlcyAiMCIgIjAiKQogICAocGFzcy1pZi1wYXJzZSBs YXN0LW1vZGlmaWVkICJUdWUsIDE1IE5vdiAxOTk0IDA4OjEyOjMxIEdNVCIKICAgICAgICAgICAg ICAgICAgKHN0cmluZy0+ZGF0ZSAiVHVlLCAxNSBOb3YgMTk5NCAwODoxMjozMSArMDAwMCIKICAg ICAgICAgICAgICAgICAgICAgICAgICAifmEsIH5kIH5iIH5ZIH5IOn5NOn5TIH56IikpKQotLSAK MS43LjIuNQoK --90e6ba1efba83cbb6204b2b4ff0a-- ------------=_1326148683-16414-1--