"modified_on" is basically the same info that is the mtime on the file. This tells you when the file has been modified, so you can return a 304, but doesn't help you with the cache. In theory all files served through download() (minus the one stored on a blob in a table) should work ok without needing any further patch (i.e. "the automation is there")
What is needed to set cache headers (and avoid the browser to request files) is some sort of "will_be_modified_on", so you can set correctly the expiration without "guessing". On Friday, February 1, 2013 5:42:59 PM UTC+1, Paolo valleri wrote: > > Something that handles the headers automatically accordingly to the wiki > media modified_on field. I will try somenthing next week (i am out this > weekend) > Il giorno 01/feb/2013 16:59, "Niphlod" <nip...@gmail.com <javascript:>> > ha scritto: > >> what "automation" ? >> >> On Friday, February 1, 2013 4:51:54 PM UTC+1, Paolo valleri wrote: >>> >>> I get it,thank for explaing. >>> I tryed a test,it seems that main.py overwrites the default headers >>> setting them as no-cache,no-store and so on. I have to test it more. >>> Moreover wiki media are handled by users,i don't know how they behave >>> with them. Something 'automatic' would be really nice to have. >>> Paolo >>> Il giorno 01/feb/2013 15:47, "Niphlod" <nip...@gmail.com> ha scritto: >>> >>>> let me explain better (PS: untested but "should" work that way) >>>> >>>> every file that is returned by the download() function does not carry >>>> any of the cache headers (to be fair, it includes one that basically says >>>> "it expires now") >>>> >>>> 304 + no content or 200 + the entire content is a step "lower" .... >>>> when a request is made with the If-Modified-Since header will check the >>>> mtime of the file and response.stream() will handle that (the logic is >>>> defined in gluon/streamer.py), returning 304 if the file has not been >>>> modified or a 200 if the file is indeed more recent. >>>> >>>> However, cache headers are useful to avoid even the requests that will >>>> end in a probable 304. >>>> In a static wiki with images, if you're sure that the published images >>>> will never change, you can enforce cache headers that will set the item to >>>> expire in some point in the future .... when cache headers are returned >>>> the >>>> browser will avoid a request with the if-modified-since header entirely. >>>> >>>> To return cache headers, you can use something like (taken from static >>>> asset management in gluon/main.py) >>>> >>>> response.headers['Cache-**Control'] = 'max-age=315360000' >>>> response.headers['Expires'] = 'Thu, 31 Dec 2037 23:59:59 GMT' >>>> >>>> This will ensure that the item would not been requested until 31 Dec >>>> 2037 (the effect is that a user will download the image one time only and >>>> will never request that image to the server again). >>>> >>>> On Friday, February 1, 2013 1:40:07 PM UTC+1, Paolo valleri wrote: >>>>> >>>>> Hi Niphlod, I don't know very well which header I have to set, can you >>>>> give me an example? >>>>> The 304 is sent by the server to the user accordingly to the user's >>>>> request. >>>>> Given that, If my upload file as a modified_on field I can actually >>>>> understand if I have to return the whole file (http: 200) or a 304. >>>>> Is it correct? >>>>> If yes, I would propose to implement something like that for >>>>> download(): >>>>> if the field as the modified_on field we can decide between 200/304, >>>>> is the field doesn't have the modified_on field we return always a 200. >>>>> >>>>> Paolo >>>>> >>>>> >>>>> 2013/2/1 Niphlod <nip...@gmail.com> >>>>> >>>>>> you have to alter the default download() function to return cache >>>>>> headers. >>>>>> The "theoretical" problem is that web2py (and then the wiki) doesn't >>>>>> know when the image stored in a table would be updated, so it doesn't >>>>>> issue >>>>>> any cache headers by default. >>>>>> >>>>>> On Thursday, January 31, 2013 9:49:21 PM UTC+1, Paolo valleri wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> today I discovered that wiki media, actually they are all images, >>>>>>> they are always requested to the server and never cached by the client. >>>>>>> In >>>>>>> other words, even if I have already visited the page I do a get to >>>>>>> download >>>>>>> all the images instead of using those in the browser cache as commonly >>>>>>> happens with for js or css. Is it a problem of my configuration or of >>>>>>> wiki >>>>>>> it self? >>>>>>> >>>>>>> paolo >>>>>>> >>>>>> -- >>>>>> >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "web2py-users" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to web2py+un...@**googlegroups.com. >>>>>> For more options, visit >>>>>> https://groups.google.com/**grou**ps/opt_out<https://groups.google.com/groups/opt_out> >>>>>> . >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "web2py-users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to web2py+un...@**googlegroups.com. >>>> For more options, visit >>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>> . >>>> >>>> >>>> >>> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "web2py-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to web2py+un...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
