unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stuart Little <achirvasub@gmail.com>
To: 37974@debbugs.gnu.org
Subject: bug#37974: eww produces "error in process filter: Specified time is not representable"
Date: Tue, 29 Oct 2019 00:51:02 -0400	[thread overview]
Message-ID: <20191029045102.GA5852@D-69-91-141-110.dhcp4.washington.edu> (raw)
In-Reply-To: <20191029003245.GA10341@arch-chirva.localdomain>

Apologies for the uninformative message below. I know slightly more now.

Setting debug-on-error and running

M-x eww RET arxiv.org RET

again produces the following trace:

--- cut here ---

Debugger entered--Lisp error: (error "Specified time is not representable")                                                                                    
  format-time-string("%a %b %d %H:%M:%S %Y GMT" (38427 52290 103040 624000) t)
  url-cookie-handle-set-cookie("browser=68.133.6.220.1572324160979722; path=/; max-age=946080000; domain=.arxiv.org")
  url-http-handle-cookies()
  url-http-parse-headers()
  url-http-chunked-encoding-after-change-function(7029 7034 5)
  url-http-generic-filter(#<process arxiv.org<1>> "0\015\n\015\n")
  read-event(nil t 2)
  sit-for(2)
  execute-extended-command(nil "eww" "eww")
  funcall-interactively(execute-extended-command nil "eww" "eww")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

--- done ---

This told me the problem was with the url-cookie-handle-set-cookie function; specifically, with the format-time-string directive therein. I tried to fiddle with it to confirm. Indeed, replacing the relevant if-then-else clause

--- cut ---

(if (and max-age (string-match "\\`-?[0-9]+\\'" max-age))                                                                                                 
       (setq expires (format-time-string "%a %b %d %H:%M:%S %Y GMT"                                                                                           
                                         (time-add nil (read max-age))                                                                                        
                                         t))                                                                                                                  
      (setq expires (cdr-safe (assoc-string "expires" args t))))

--- done ---

therein with just the else branch

(setq expires (cdr-safe (assoc-string "expires" args t)))

resolves the issue. arxiv.org loads fine with the redefined url-cookie-handle-set-cookie function. 

On Mon, Oct 28, 2019 at 08:32:45PM -0400, Stuart Little wrote:
> I am on a Debian 10.1 machine i686. The current Emacs version in this Debian repo is 26.1.
> 
> My issue is that
> 
> M-x eww RET arxiv.org RET
> 
> fails to load the page and produces the error
> 
> error in process filter: Specified time is not representable
> 
> in the minibuffer. Other websites load fine (e.g. nytimes.com, theguardian.comn, google.com). Others, on the other hand, simply silently time out: duckduckgo.com and thenation.com behave this way (the minibuffer reports 'contacting host' but the page never loads).
> 
> Everything loads fine on an Arch Linux x86_64 machine running Emacs 26.3 as well as an Android 9 phone running an ARM version of Emacs 26.3 in a terminal emulator (Termux), so it is not a network issue.
> 
> Additionally, a separate machine running Linux Mint 19.2 an Emacs 25.2.2 loads arxiv.org without issue.





  reply	other threads:[~2019-10-29  4:51 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-29  0:32 bug#37974: eww produces "error in process filter: Specified time is not representable" Stuart Little
2019-10-29  4:51 ` Stuart Little [this message]
2019-10-29 10:25   ` Stuart Little
2019-10-29 12:05     ` A.C.
2019-10-29 12:47       ` Lars Ingebrigtsen
2019-10-29 14:06         ` A.C.
2019-10-29 14:41           ` A.C.
2019-10-29 21:52           ` Lars Ingebrigtsen
2019-10-29 22:23             ` A.C.
2019-10-30 10:19               ` Colin Baxter
2019-10-30 11:01                 ` Lars Ingebrigtsen
2019-10-31 18:50                   ` A.C.
2019-11-01 13:46                     ` Lars Ingebrigtsen
2019-11-01  8:05 ` Paul Eggert
2019-11-01 23:22   ` Paul Eggert
2019-11-02  7:34     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191029045102.GA5852@D-69-91-141-110.dhcp4.washington.edu \
    --to=achirvasub@gmail.com \
    --cc=37974@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).