Hi Niphlod, I am still trying to understand why the wiki uploads are not returned as 304. The function in charged to return either 200 or 304 is stream_file_or_304_or_206 in streamer.py. Moreover, this function is only called in globals.py inside stream(...). Please have a look at globals.py:344, In order to be called the parameter 'stream' must be a string but with 'common' downloads the stream is an open file. This is also documented by the comment in dal.py:9096. is what I've written correct ?
Paolo 2013/2/1 Niphlod <niph...@gmail.com> > "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> 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-**Contro**l'] = '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/**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+unsubscr...@googlegroups.com. > 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.
