Re: [PATCH] gitweb: check if-modified-since for feeds

[Jakub Narebski <jnareb@gmail.com>]

On Mon, 26 Jan 2009, Giuseppe Bilotta wrote:
> On Mon, Jan 26, 2009 at 3:18 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Sun, 25 Jun 2009, Giuseppe Bilotta wrote:

>>> -             %latest_date   = parse_date($latest_commit{'committer_epoch'});
>>> +             my $latest_epoch = $latest_commit{'committer_epoch'};
>>> +             %latest_date   = parse_date($latest_epoch);
>>> +             my $if_modified = $cgi->http('IF_MODIFIED_SINCE');
>>> +             if (defined $if_modified) {
>>> +                     my $since;
>>> +                     if (eval { require HTTP::Date; 1; }) {
>>> +                             $since = HTTP::Date::str2time($if_modified);
>>> +                     } elsif (eval { require Time::ParseDate; 1; }) {
>>> +                             $since = Time::ParseDate::parsedate($if_modified, GMT => 1);
>>> +                     }
>>
>> I'd really like to fallback on hand-parsing, as we have to parse date
>> in well defined HTTP-date format (RFC-1123, update to RFC-822), which
>> I think is what we send in Last-Modified header (or is it RFC-2822?).
>>
>> But that might be too much work. I like the checking for modules,
>> and the fallback cascade, but could you explain why in this order?
> 
> Of course, if we have our own parsing code, we don't need the other
> modules. I'm way too lazy to write the parsing code myself, although a
> copypaste from existing GPL code would do it.
> 
> (BTW, I asked on #perl and they think gitweb non-reliance on CPAN
> makes for some very horrible code. Of course, IMO the real problem is
> that perl's stdlib is way too limited, but that is likely to causes a
> language war so I refrained from discussing the thing.)

The problem is (which was discussed on git mailing list) that gitweb
is to be run on servers.  And admins are very reluctant on putting
anything but well tested software on server.  The order is: in standard
installation, in core distribution, in extras package of distribution,
in trusted extras repository... random CPAN package is usually out of
the question.

> 
> The order is almost casual, but I suspect that HTTP::Date, from
> libwww-perl, is more likely to be available on a webserver than the
> other.

True.

BTW. I have thought that we already require libwww-perl with the
modules we use in gitweb, but they are all packaged with Perl.

While I don't think that there would be many complaints requiring
libwww-perl, I'd rather have it optional...

-- 
Jakub Narebski
Poland