On 11/14/2012 03:53 PM, André Warnier wrote:
> The tidbit above makes me think about a possibility to solve another
> issue that happens from time to time : some users browsers that are NOT
> refreshing their copies of stylesheets or javascript libraries, even
> though they have been modified.
> No
Torsten Förtsch wrote:
On 11/14/2012 02:48 PM, André Warnier wrote:
I my particular case, the sendfile() solution above works fine, because
I am sure in this case that no additional processing needs to take place
on those static pages.
What I meant in particular was the HTTP code 304 generatio
On 11/14/2012 02:48 PM, André Warnier wrote:
> I my particular case, the sendfile() solution above works fine, because
> I am sure in this case that no additional processing needs to take place
> on those static pages.
What I meant in particular was the HTTP code 304 generation. With your
solution
Torsten Förtsch wrote:
On 11/13/2012 07:17 PM, André Warnier wrote:
I didn't want to take too much time of anyone before, which is why I
somewhat oversimplified the issue. But considering the traffic on the
lis os low, maybe you want to hear the whole story after all.
The basic case is this :
On 11/13/2012 07:17 PM, André Warnier wrote:
> I didn't want to take too much time of anyone before, which is why I
> somewhat oversimplified the issue. But considering the traffic on the
> lis os low, maybe you want to hear the whole story after all.
>
> The basic case is this : a bit aside from
Sure thing, anytime.
You raise valid points and are in the best position to know what kind of
tradeoffs to make. Simpler handler requires less processing and memory
but increased number of requests.
I said what I did because I'm working on a single page app. with heavy
use of Javascript (Go
Torsten Förtsch wrote:
On 11/12/2012 06:19 PM, André Warnier wrote:
In response to some request URLs, I have to compose a response
structured as follows :
- a html frameset document with two frames
- in the 1st frame, the result of another HTTP request to the same
Apache server.
This URI of t
On 11/12/2012 06:19 PM, André Warnier wrote:
> In response to some request URLs, I have to compose a response
> structured as follows :
>
> - a html frameset document with two frames
> - in the 1st frame, the result of another HTTP request to the same
> Apache server.
> This URI of this HTTP req
Hi.
Once again, thanks. Your javascript/onLoad idea sounds good, and would fit my
needs.
I'll give it a spin.
There is one thing that bothers me (and it is the same in my own solution outlined below)
: what previously was one HTTP request and one response, now becomes 3 HTTP requests and 3
r
Hi.
Thank you for your response.
You are not missing the point of my questions.
But I do not really have control over the requests. Or rather, I do, but there are
hundreds of pages containing hundreds of similar (but not equal) links, and it is in the
practice not doable to edit them all..
And
Q1: At first glance, using a mod_perl handler to serve an existing
static html file seems like overkill.
Couldn't Apache respond (RedirectMatch?) with a common frameset html
file with some Javascript, which then fills the first frame with the
response to mangle.pl and the second frame with t
Hi.
context: Apache2.x, mod_perl 2.x
In response to some request URLs, I have to compose a response structured as
follows :
- a html frameset document with two frames
- in the 1st frame, the result of another HTTP request to the same Apache
server.
This URI of this HTTP request is created b
12 matches
Mail list logo
