Re: [fossil-users] fossil-users Digest, Vol 121, Issue 22

[Ron W]

On Sun, Feb 25, 2018 at 7:00 AM, 
wrote:

>
> Date: Sun, 25 Feb 2018 04:37:38 -0500
> From: Ron W 
> Subject: Re: [fossil-users] Minor Issues with Fossil 2.5
>
> > Date: Sun, 25 Feb 2018 10:11:04 +0100
> > From: Florian Balmer  > Subject: Re: [fossil-users] Minor Issues with Fossil 2.5
> >
> > I think that the "Last-Modified" header is much easier to handle, as
> > it boils down to parsing a GMT date/time string. And, as already
> > mentioned, clobbering of locally-modified files can be avoided with
> > the timestamp mechanism, this is not possible with an ETag alone.
>

Sorry, I missed the locally modified part.

But, it sounds like you expect it to be overwritten by a newer "version"
from the remote resource.

ETag can handle that case as well.

In the wget.pl wrapper I linked, an ETag "jar" is maintained. So, wget.pl
doesn't care about any local changes. It will only fetch the remote
resource when the resource's ETag value has changed.

Another suggestion: Treat unversioned files like 3rd party "vendor
releases" and keep locally modified copies in a separate location. That
way, the newly fetched copy can't accidently overwrite your local changes.

The ETag is supposed to only change when the content changes Therefore, if
> the Etag you have is not the same as the current ETag on the server - for
> the same resource - then the content is different.
>
> Admittedly, if the server's copy of the resource is changed to an older
> version, the ETag will be different, as well.
>
> So, if you always need the newest version, then modification time is
> needed. But if different is acceptable, then Etag will do that.
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Minor Issues with Fossil 2.5

[Richard Hipp]

On 2/25/18, Florian Balmer  wrote:
> As far as I remember, I've come across the recommendation to combine
> ETags and Last-Modified headers, so the client could pick
> If-None-Match or If-Modified-Since to validate its cached content.
>
> And, it's already there, and works like a charm!

Yes.  But because of the issue described previously, I wonder if I
shouldn't drop support for If-Modified-Since?  Do we know that all
clients that support both If-None-Match and If-Modified-Since will
always choose If-None-Match if it is available from the server?  In
that case, it might be acceptable to leave in support for
If-Modified-Since.  But if the presence of If-Modified-Since might
cause some clients to use it in place of If-None-Match, then we should
take it out.

Does anybody know?

Is there any reader on this list who as parsed the text of the
relevant RFCs and knows the answer?  Can you brief me, and prehaps
give a link to the appropriate standard?

At the very least, I should probably fix Fossil so that never sends a
Last-Modified reply header (used by If-Modified-Since) unless there is
also an ETag header.  That would prevent incorrect answers on any
client ETag capable and which always prioritizes ETag over
Last-Modified.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Minor Issues with Fossil 2.5

[Florian Balmer]

D. Richard Hipp:

> Consider this sequence of operations:
>
> (1) User A does a "uv push"
> (2) User B does a "wget -N" against the uv.
> (3) User C does a "uv push" of different content.
>
> If all of (1), (2), and (3) happen during the same second and if
> unversioned content honors the If-Modified-Since header, then
> subsequent attempts by user B to do "wget -N" will continue to
> retrieve the obsolete version of the unversioned content that was
> uploaded by user A. User B will never see the more recent content
> uploaded by user C.

Yes, I agree.

It's the same situation as if multiple users were sharing files on a
web server space not under version control, with uploads by FTP ("uv
push") and downloads by HTTP ("wget -N").

This may work well for "inert" files, requiring small temporary local
adaptations not worth archiving, but bothersome if overwritten by an
accidental "wget". However, "mission-critical" and "fast-changing"
files, for which the risk of loosing content is unacceptable, had
better be put under version control.

As far as I remember, I've come across the recommendation to combine
ETags and Last-Modified headers, so the client could pick
If-None-Match or If-Modified-Since to validate its cached content.

And, it's already there, and works like a charm!

Thank you very much for all your efforts you're putting into this
project, this is really appreciated!

--Florian
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Minor Issues with Fossil 2.5

[Richard Hipp]

On 2/23/18, Florian Balmer  wrote:
>
> 2. There's no "Last-modified" HTTP header when downloading unversioned
> files through the /uv web page, causing undesired network traffic for
> `wget -N' scripting scenarios,

Consider this sequence of operations:

(1) User A does a "uv push"
(2) User B does a "wget -N" against the uv.
(3) User C does a "uv push" of different content.

If all of (1), (2), and (3) happen during the same second and if
unversioned content honors the If-Modified-Since header, then
subsequent attempts by user B to do "wget -N" will continue to
retrieve the obsolete version of the unversioned content that was
uploaded by user A.  User B will never see the more recent content
uploaded by user C.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Minor Issues with Fossil 2.5

[Ron W]

On Sun, Feb 25, 2018 at 4:11 AM, 
wrote:

>
> Date: Sun, 25 Feb 2018 10:11:04 +0100
> From: Florian Balmer  Subject: Re: [fossil-users] Minor Issues with Fossil 2.5
>
> I think that the "Last-Modified" header is much easier to handle, as
> it boils down to parsing a GMT date/time string. And, as already
> mentioned, clobbering of locally-modified files can be avoided with
> the timestamp mechanism, this is not possible with an ETag alone.
>

The ETag is supposed to only change when the content changes Therefore, if
the Etag you have is not the same as the current ETag on the server - for
the same resource - then the content is different.

Admittedly, if the server's copy of the resource is changed to an older
version, the ETag will be different, as well.

So, if making you always need the newest version, then modification time is
needed. But if different is acceptable, then Etag will do that.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Minor Issues with Fossil 2.5

[Florian Balmer]

Ron:

> Someone already made an ETag wrapper for wget:
> https://www.w3.org/2001/12/rubyrdf/pack/tests/scutter/wget.pl

Thanks for the interesting link.

> There is no requirement or specification for the value of an ETag,
> could use the Fossil artifact hash as the ETag value. Then a script
> trying to fetch the file can generate the value from the current copy
> of the file.

I agree, but with the current implementation, at least the
 ingredient is hard to guess for a client script trying to
generate a Fossil ETag.

I think that the "Last-Modified" header is much easier to handle, as
it boils down to parsing a GMT date/time string. And, as already
mentioned, clobbering of locally-modified files can be avoided with
the timestamp mechanism, this is not possible with an ETag alone.

--Florian
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users