Re: RSS If-Modified-Since

Re: RSS If-Modified-Since

[Ted Zlatanov]

On Sat, 16 Feb 2008 04:15:36 +0800 jidanni@jidanni.org wrote: 

j> Well OK but I bet
j> If-modified-since: Wednesday, 13-Feb-08 00:45:19 GMT
j> means 1908.

You may be right, RFC 850 doesn't specify the conversion.  Sorry I
didn't consider that in my original response (typical engineer response
to man in balloon asking "where am I" -- "in the air" :)

I don't know if the date should be 1900+x or (1900+x when x > 50, 2000+x
otherwise).  I'll bet that's one of the reasons RFC 850 is obsolete, so
let's instead try to fix the root problem.

So, what's sending that header?  In Emacs 22, it seems to be
lisp/url/url-util.el:url-get-normalized-date and it definitely has the
behavior you noted.  Since the bug may affect other things (there's a
comment about Plexus servers in the code) I won't attempt to fix it
myself, though it's not hard to do.  Please, emacs-devel-opers, let me
know if I should submit a fix.

I think format-time-string is the right function to do this, but there's
probably subtleties that I don't know.  At least for time zones,
format-time-string will handle them correctly.

j> Say, I use Debian sid  emacs-version "22.1.1" gnus-version "Gnus v5.11".
j> If I wish to help out by reporting against a more current gnus, which
j> one should I download and use? Would I have to also install a more
j> current emacs? Too much trouble then...

To report Gnus bugs, it's most helpful to check against the latest Gnus
from CVS.  That should not require an extremely new Emacs (22 should be
OK), but I don't know for sure, sorry.  I use Emacs from CVS for other
reasons.

Ted

make standard If-Modified-Since headers

[jidanni]

Can you people please make If-Modified-Since headers like say,
firefox? Here is an If-Modified-Since header made by firefox:
If-Modified-Since: Wed, 13 Feb 2008 00:45:19 GMT

>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:

TZ> On Sat, 16 Feb 2008 04:15:36 +0800 jidanni@jidanni.org wrote: 
j> Well OK but I bet
j> If-modified-since: Wednesday, 13-Feb-08 00:45:19 GMT
j> means 1908.

TZ> You may be right, RFC 850 doesn't specify the conversion.  Sorry I
TZ> didn't consider that in my original response (typical engineer response
TZ> to man in balloon asking "where am I" -- "in the air" :)

TZ> I don't know if the date should be 1900+x or (1900+x when x > 50, 2000+x
TZ> otherwise).  I'll bet that's one of the reasons RFC 850 is obsolete, so
TZ> let's instead try to fix the root problem.

TZ> So, what's sending that header?  In Emacs 22, it seems to be
TZ> lisp/url/url-util.el:url-get-normalized-date and it definitely has the
TZ> behavior you noted.  Since the bug may affect other things (there's a
TZ> comment about Plexus servers in the code) I won't attempt to fix it
TZ> myself, though it's not hard to do.  Please, emacs-devel-opers, let me
TZ> know if I should submit a fix.

TZ> I think format-time-string is the right function to do this, but there's
TZ> probably subtleties that I don't know.  At least for time zones,
TZ> format-time-string will handle them correctly.

Re: make standard If-Modified-Since headers

[Ted Zlatanov]

>>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:

TZ> On Sat, 16 Feb 2008 04:15:36 +0800 jidanni@jidanni.org wrote: 
j> Well OK but I bet
j> If-modified-since: Wednesday, 13-Feb-08 00:45:19 GMT
j> means 1908.

TZ> You may be right, RFC 850 doesn't specify the conversion.  Sorry I
TZ> didn't consider that in my original response (typical engineer response
TZ> to man in balloon asking "where am I" -- "in the air" :)

TZ> I don't know if the date should be 1900+x or (1900+x when x > 50, 2000+x
TZ> otherwise).  I'll bet that's one of the reasons RFC 850 is obsolete, so
TZ> let's instead try to fix the root problem.

TZ> So, what's sending that header?  In Emacs 22, it seems to be
TZ> lisp/url/url-util.el:url-get-normalized-date and it definitely has the
TZ> behavior you noted.  Since the bug may affect other things (there's a
TZ> comment about Plexus servers in the code) I won't attempt to fix it
TZ> myself, though it's not hard to do.  Please, emacs-devel-opers, let me
TZ> know if I should submit a fix.

TZ> I think format-time-string is the right function to do this, but there's
TZ> probably subtleties that I don't know.  At least for time zones,
TZ> format-time-string will handle them correctly.

On Wed, 27 Feb 2008 07:44:37 +0800 jidanni@jidanni.org wrote: 

j> Can you people please make If-Modified-Since headers like say,
j> firefox? Here is an If-Modified-Since header made by firefox:
j> If-Modified-Since: Wed, 13 Feb 2008 00:45:19 GMT

Please note that this is not Firefox-specific.  The date format is a RFC
specification, and currently url-get-normalized-date is returning the
RFC 850 format which is obsoleted by the newer relevant RFC.

As I said, I'll write a fix if necessary, but wanted to ask for opinions
to make sure existing code (especially parsers that might depend on the
old format) doesn't break.

Ted

Re: make standard If-Modified-Since headers

[Thien-Thi Nguyen]

() Ted Zlatanov <tzz@lifelogs.com>
() Wed, 27 Feb 2008 09:08:43 -0600

   to ask for opinions to make sure existing code (especially
   parsers that might depend on the old format) doesn't break.

If there's a newer RFC, code relying on the old RFC will break
when trying to interoperate elsewhere (outside Emacs), unless
their maintainers can be alerted sooner by Emacs moving to the
newer RFC.  If it MUST be broken sooner or later, better sooner.

thi

Re: make standard If-Modified-Since headers

[Ted Zlatanov]

On Wed, 27 Feb 2008 16:22:35 +0100 Thien-Thi Nguyen <ttn@gnuvola.org> wrote: 

TN> () Ted Zlatanov <tzz@lifelogs.com>
TN> () Wed, 27 Feb 2008 09:08:43 -0600

TN>    to ask for opinions to make sure existing code (especially
TN>    parsers that might depend on the old format) doesn't break.

TN> If there's a newer RFC, code relying on the old RFC will break
TN> when trying to interoperate elsewhere (outside Emacs), unless
TN> their maintainers can be alerted sooner by Emacs moving to the
TN> newer RFC.  If it MUST be broken sooner or later, better sooner.

The newer RFC (http://www.faqs.org/rfcs/rfc2616.html, section 19.3 and
others) specifies the older format (RFC 850 HTTP dates, which have
2-digit years) as acceptable input, but in practice years like 2008 are
often not handled properly in the 2-digit format, and there's no need to
use RFC 850 dates today.  

I am not aware of anything inside Emacs that cares about the
url-get-normalized-date format.

I think this is a very harmless bug fix that should go in the pretest as
well.  If anyone has a reason to stick with RFC 850 dates, please let me
know.

Ted

Re: make standard If-Modified-Since headers

[Ted Zlatanov]

The specific function change I am proposing, so we have a specific
reference point:

(defun url-get-normalized-date (&optional specified-time)
  "Return a 'real' date string that most HTTP servers can understand."
  (let ((system-time-locale "C"))
    (format-time-string "%a, %d %b %Y %T %Z" 
                        (or specified-time (current-time)))))

Will this work on all systems?  It avoids the hardcoded week and month
abbreviations through the locale specification, but I can only test that
on Linux.

Ted

Re: make standard If-Modified-Since headers

[Jason Rumney]

Ted Zlatanov wrote:
> The specific function change I am proposing, so we have a specific
> reference point:
>
> (defun url-get-normalized-date (&optional specified-time)
>   "Return a 'real' date string that most HTTP servers can understand."
>   (let ((system-time-locale "C"))
>     (format-time-string "%a, %d %b %Y %T %Z" 
>                         (or specified-time (current-time)))))
>
> Will this work on all systems?  It avoids the hardcoded week and month
> abbreviations through the locale specification, but I can only test that
> on Linux.
>   

IIRC, only a small subset of timezone names are allowed in HTTP headers, 
so %z would be better than %Z, or alternatively hardcode GMT:
...
(format-time-string "%a, %d %b %Y %T GMT"
         (or specified-time (current-time)) t)
...


%Z seems to give an empty string here (Windows XP), but that is probably 
a bug.

Re: make standard If-Modified-Since headers

[Jason Rumney]

Jason Rumney wrote:
> IIRC, only a small subset of timezone names are allowed in HTTP 
> headers, so %z would be better than %Z, or alternatively hardcode GMT:

In fact, RFC2616 (3.3.1) states: "All HTTP date/time stamps MUST be 
represented in Greenwich Mean Time (GMT), without exception. For the 
purposes of HTTP, GMT is exactly equal to UTC (Coordinated Universal Time)."

So hardcoding GMT here is correct.

Re: make standard If-Modified-Since headers

[Ted Zlatanov]

On Wed, 27 Feb 2008 22:24:07 +0000 Jason Rumney <jasonr@gnu.org> wrote: 

JR> IIRC, only a small subset of timezone names are allowed in HTTP
JR> headers, so %z would be better than %Z, or alternatively hardcode GMT:
JR> ...
JR> (format-time-string "%a, %d %b %Y %T GMT"
JR>         (or specified-time (current-time)) t)
...
JR> In fact, RFC2616 (3.3.1) states: "All HTTP date/time stamps MUST be
JR> represented in Greenwich Mean Time (GMT), without exception. For the
JR> purposes of HTTP, GMT is exactly equal to UTC (Coordinated Universal
JR> Time)."

JR> So hardcoding GMT here is correct.

Cool, thanks for clarifying.  So the function will now read:

(defun url-get-normalized-date (&optional specified-time)
 "Return a 'real' date string that most HTTP servers can understand."
 (let ((system-time-locale "C"))
  (format-time-string "%a, %d %b %Y %T GMT"
   (or specified-time (current-time)) t)))

Is that OK with everyone?  It needs to go into both the test release as
a bug fix and into the CVS HEAD.

I should still have CVS commit permissions from savannah so I can commit
this, if it's OK with the maintainers.

Ted

Re: make standard If-Modified-Since headers

[Stefan Monnier]

JR> IIRC, only a small subset of timezone names are allowed in HTTP
JR> headers, so %z would be better than %Z, or alternatively hardcode GMT:
JR> ...
JR> (format-time-string "%a, %d %b %Y %T GMT"
JR> (or specified-time (current-time)) t)
> ...
JR> In fact, RFC2616 (3.3.1) states: "All HTTP date/time stamps MUST be
JR> represented in Greenwich Mean Time (GMT), without exception. For the
JR> purposes of HTTP, GMT is exactly equal to UTC (Coordinated Universal
JR> Time)."

JR> So hardcoding GMT here is correct.

> Cool, thanks for clarifying.  So the function will now read:

> (defun url-get-normalized-date (&optional specified-time)
>  "Return a 'real' date string that most HTTP servers can understand."
>  (let ((system-time-locale "C"))
>   (format-time-string "%a, %d %b %Y %T GMT"
>    (or specified-time (current-time)) t)))

> Is that OK with everyone?  It needs to go into both the test release as
> a bug fix and into the CVS HEAD.

> I should still have CVS commit permissions from savannah so I can commit
> this, if it's OK with the maintainers.

Seeing how the previous code is a good bit more complex, the change
looks good.


        Stefan

Re: make standard If-Modified-Since headers

[Robert J. Chassell]

Most HTTP date/time stamps use the numeric form which in this
symbolism has a small z, %z.

For example, Ted Zlatanov wrote on 

    Date: Wed, 27 Feb 2008 16:45:26 -0600

Even when (system-time-locale "C") produces UTC, it would make sense
to provide

(defun url-get-normalized-date (&optional specified-time)
 "Return a 'real' date string that most HTTP servers can understand."
 (let ((system-time-locale "C"))
   (format-time-string "%a, %d %b %Y %T %z"
   (or specified-time (current-time)) t)))

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: make standard If-Modified-Since headers

[Ted Zlatanov]

On Thu, 28 Feb 2008 02:31:05 +0000 (UTC) "Robert J. Chassell" <bob@rattlesnake.com> wrote: 

RJC> Most HTTP date/time stamps use the numeric form which in this
RJC> symbolism has a small z, %z.

On Wed, 27 Feb 2008 20:46:34 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> Seeing how the previous code is a good bit more complex, the change
SM> looks good.

Thanks, everyone.  I used UTC in the end, and hard-coded "GMT" in the
time string to be fully compatible with the RFC, which uses "GMT".  It
can be UTC or a numeric offset too, and the change is trivial.

I comitted the change in CVS HEAD; please let me know if I should commit
it to the pretest branch as well.

Ted

Re: make standard If-Modified-Since headers

[Stefan Monnier]

> Thanks, everyone.  I used UTC in the end, and hard-coded "GMT" in the
> time string to be fully compatible with the RFC, which uses "GMT".  It
> can be UTC or a numeric offset too, and the change is trivial.

> I comitted the change in CVS HEAD;

Thanks.

> please let me know if I should commit it to the pretest branch as well.

We may as well,


        Stefan

Re: make standard If-Modified-Since headers

[Ted Zlatanov]

On Thu, 28 Feb 2008 13:23:22 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> please let me know if I should commit it to the pretest branch as well.

SM> We may as well,

Since EMACS_PRETEST_22_1_91 (the only mention of the pretest I could
find) is a tag, not a branch, I can't commit to it.  This is my first
time working with the pretest, so if you can explain what I should (or
shouldn't) do I'd appreciate it.

Ted

Re: make standard If-Modified-Since headers

[Miles Bader]

Ted Zlatanov <tzz@lifelogs.com> writes:
> SM> We may as well,
>
> Since EMACS_PRETEST_22_1_91 (the only mention of the pretest I could
> find) is a tag, not a branch, I can't commit to it.  This is my first
> time working with the pretest, so if you can explain what I should (or
> shouldn't) do I'd appreciate it.

Commit to the branch instead (checkout the branch, and commit).

-Miles

-- 
Religion, n. A daughter of Hope and Fear, explaining to Ignorance the nature
of the Unknowable.

Re: make standard If-Modified-Since headers

[Stefan Monnier]

>>> please let me know if I should commit it to the pretest branch as well.

SM> We may as well,

> Since EMACS_PRETEST_22_1_91 (the only mention of the pretest I could
> find) is a tag, not a branch, I can't commit to it.

Not only that but 22.1.91 was "released" already, so clearly there's no
point trying to change it.  22.1.92 will be cut from the 22 branch, aka
EMACS_22_BASE.

> This is my first time working with the pretest, so if you can explain
> what I should (or shouldn't) do I'd appreciate it.

cvs update -r EMACS_22_BASE
...edit the file and the ChangeLog...
cvs diff -u
...make sure the changes correspond to what you meant to commit...
cvs commit -m "the message"


        Stefan

Re: make standard If-Modified-Since headers

[Ted Zlatanov]

On Thu, 28 Feb 2008 14:20:30 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>>> please let me know if I should commit it to the pretest branch as well.
SM> We may as well,

>> Since EMACS_PRETEST_22_1_91 (the only mention of the pretest I could
>> find) is a tag, not a branch, I can't commit to it.

SM> Not only that but 22.1.91 was "released" already, so clearly there's no
SM> point trying to change it.  22.1.92 will be cut from the 22 branch, aka
SM> EMACS_22_BASE.

>> This is my first time working with the pretest, so if you can explain
>> what I should (or shouldn't) do I'd appreciate it.

SM> cvs update -r EMACS_22_BASE
SM> ...edit the file and the ChangeLog...
SM> cvs diff -u
SM> ...make sure the changes correspond to what you meant to commit...
SM> cvs commit -m "the message"

Done.  Sorry for the noise, and thanks.

Ted

Re: make standard If-Modified-Since headers

[Reiner Steib]

On Thu, Feb 28 2008, Ted Zlatanov wrote:

> Since EMACS_PRETEST_22_1_91 (the only mention of the pretest I could
> find) is a tag, not a branch, I can't commit to it.  

The pretests are released from the branch EMACS_22_BASE (CMIIW).

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: make standard If-Modified-Since headers

[Robert J. Chassell]

    %Z seems to give an empty string here (Windows XP), but that is probably 
    a bug.

It is a bug.  On my Debian GNU/Linux system, %Z has for years matched
its documentation

    %Z is the time zone name

Using %Z is safer than using UTC or an equivalent since some computers
are configured to provide Central European Time, others Pacific
Standard Time, and so on.

For me, the current date and time (from a function I keep in my .emacs
file):

    Thu, 2008 Feb 28  01:58 UTC

(GMT went away in the 1970s; I remember it from my youth.  There are a
variety of ephemeric and atomic clock times.  UTC is the French
abbreviation for Universal Coordinated Time which is used in making
time zones around the planet, for weather reports, and that sort of
thing.  It is also known as `Zulu time' so you will see an
abbreviation such as 00Z in a weather discussion, meaning 7pm EST or
8pm EDT.)

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: make standard If-Modified-Since headers

[Juanma Barranquero]

On Thu, Feb 28, 2008 at 3:16 AM, Robert J. Chassell <bob@rattlesnake.com> wrote:

> UTC is the French
>  abbreviation for Universal Coordinated Time

"Why is UTC used as the acronym for Coordinated Universal Time instead of CUT?

      In 1970 the Coordinated Universal Time system was devised by an
international advisory group of technical experts within the
International Telecommunication Union (ITU). The ITU felt it was best
to designate a single abbreviation for use in all languages in order
to minimize confusion. Since unanimous agreement could not be achieved
on using either the English word order, CUT, or the French word order,
TUC, the acronym UTC was chosen as a compromise."

From http://tf.nist.gov/general/misc.htm#Anchor-14550 which is as
official as it gets.

             Juanma

Re: make standard If-Modified-Since headers

[Stefan Monnier]

>    to ask for opinions to make sure existing code (especially
>    parsers that might depend on the old format) doesn't break.

> If there's a newer RFC, code relying on the old RFC will break
> when trying to interoperate elsewhere (outside Emacs), unless
> their maintainers can be alerted sooner by Emacs moving to the
> newer RFC.  If it MUST be broken sooner or later, better sooner.

Yes, we should use the newer RFC format.


        Stefan