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" <niph...@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-**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+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.
