Great! I've just tested it and it seems to work very well, I am getting the
304 that I was looking for. Now many resources are no longer sent to the
client saving bandwidth, I think many web2py applications will appreciate
this speed up.
@Niphlod, the header you have mentioned will force to keep
On Tuesday, February 5, 2013 2:49:24 PM UTC+1, Paolo valleri wrote:
Great! I've just tested it and it seems to work very well, I am getting
the 304 that I was looking for. Now many resources are no longer sent to
the client saving bandwidth, I think many web2py applications will
I am wondering to understand if from the theoretical point of view is true
or not that parallel requests are not handled in parallel. In the meanwhile
I will try to monitor the gain that we can have by session.forget in all
the downloads().
Paolo
2013/2/5 Niphlod niph...@gmail.com
On
Not sure I understand the question.
There are two issues. One is about sessions. Distinct requests from the
same user/session are serialized unless session._unlock(request) is called.
Requests belonging to different session are executed in different threads
but to a max number of threads
On Tuesday, February 5, 2013 5:30:11 PM UTC+1, Massimo Di Pierro wrote:
Not sure I understand the question.
I think the doubt lies into the fact that given 1 request for the wiki page
and ,e.g., 4 requests for 4 embedded images the 5 requests would be
concurrent or serialized. In my apps
Niphlod has written exactly what I have in mind.
Given the fact that distinct requests from the same user/session are
serialized as Massimo has outlined from my point of view we should add
session.forget() or session._unlock(request) as early as possible in the
download() function of globals.py
I agree. In trunk.
they both unlock but session.forget(response) does not save the session.
session._unlock(response) instead still saves the session when the request
is completed.
On Tuesday, 5 February 2013 12:33:03 UTC-6, Paolo valleri wrote:
Niphlod has written exactly what I have in
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,
On Monday, February 4, 2013 3:38:29 PM UTC+1, Paolo valleri wrote:
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
I thought the same about postponing the opening of the file. Moreover, just
after globals:344 in the stream(...) function I have added
if isinstance(stream, file):
stream_file_or_304_or_206(stream.name,
chunk_size=chunk_size,
Honestly I would like to refactor all this logic in web2py. It was already
done for web3py:
https://github.com/mdipierro/web3py/blob/master/web3py/stream.py
Anyway, if you can help fix it in web2py, we can merge everything later
Massimo
On Monday, 4 February 2013 11:46:03 UTC-6, Paolo valleri
Uhm, I was just thinking to return a string instead of the open stream.
attached the patch (some refactoring bits added)
@Paolo: turns out that wiki has it's own download() function to handle
files . in order to return cache headers you should do:
def yourwikiindex():
zero =
In trunk!
On Monday, 4 February 2013 15:05:05 UTC-6, Niphlod wrote:
Uhm, I was just thinking to return a string instead of the open stream.
attached the patch (some refactoring bits added)
@Paolo: turns out that wiki has it's own download() function to handle
files . in order to
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
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
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
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.
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
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
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
20 matches
Mail list logo
