Am Freitag, 15. Mai 2015, 14:38:08 schrieb Giuseppe Scrivano: > Tim Rühsen <[email protected]> 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
