Re: [Bug-wget] Conditional GET requests

[Tim Rühsen]

Am Freitag, 15. Mai 2015, 14:38:08 schrieb Giuseppe Scrivano:
> Tim Rühsen <address@hidden> writes:
> > Am Donnerstag, 14. Mai 2015, 15:43:54 schrieb Hubert Tarasiuk:
> >> W dniu 13.05.2015 o 13:28, Ander Juaristi pisze:
> >> > And second, I'm not really sure whether --condget is the best name for
> >> > the switch.
> >> > Requests that include any of If-Unmodified-Since, If-Match,
> >> > If-None-Match, or If-Range
> >> > header fields are also "conditional GETs" as well.
> >> > We might want to implement one of those in the future and we'd be
> >> > forced
> >> > to choose a name which could easily be
> >> > inconsistent/confusing with --condget. Or maybe we won't. But we don't
> >> > know that now, so I think
> >> > it's better to choose a switch more specific to the fact that an
> >> > If-Modified-Since header will be sent
> >> > so as to avoid confusion.
> >> 
> >> Do you have an idea for a better switch name that would not be too long?
> >> I have noticed that issue earlier, but could not think of a better name
> >> that would not be too long. :D
> >> 
> >> Thank you for the suggestions,
> > 
> > Hi Hubert,
> > 
> > why not --if-modified-since as a boolean option ?
> > 
> > I personally would set it to true by default, since it is a very
> > common/basic HTTP 1.1 header.
> 
> would not be better to not enable it by default?  At least this is what
> we do with --timestamping and having --if-modified-since by default will
> break the use case of downloading successive files as .1, .2, .3....

One GET including If-modified-since simply should replace the two requests 
HEAD + GET (or one HEAD if this says 'no update'). Why should the backup 
strategy of Wget change ? Maybe I am just wrong... please explain a bit more 
in detail.

Regards, Tim