perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gAzZaLi <>
Subject Re: question on sub-requests
Date Tue, 13 Nov 2012 18:39:23 GMT

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 (Google's Closure) and happened to think of it.

If you're trying to serve valid HTML content in two frames as one valid
HTML page or output, then perhaps reexamining your problem will give you 
some other insight.

On 11/13/2012 1:04 AM, André Warnier wrote:
> 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 responses (one pair for the
> initial request; one pair each for each of the frames).
> It bothers me intellectually, because one of the points of this whole
> exercise was to make the whole process more efficient. I was hoping to
> be able to send back the whole frameset with the frames in it (and their
> content) in the initial response.  But that is not valid html.
> Oh well..
> On the other hand, this customer pays for bandwidth used. ;-)
> gAzZaLi wrote:
>> Hi, you're welcome, glad to be of any help.
>> Sounds like you're close to getting it done or done
>> with it already.
>> If you're interested, here's the redirect idea in a little
>> more detail and doesn't involve edits or renaming.
>> All requests to html files in /abc/def/ could be handled with, say,
>> RedirectMatch ^/abc/def/(.*)\.html$ /common/global.html?$1
>> which loads the frameset file global.html (in the 'common' dir.) with
>> a param in the URL that denotes the actual file that was requested.
>> Since the static file at /abc/def/ghi.html will be served up in the
>> bottom frame, and should not be intercepted by the RedirectMatch
>> above, /abc/def could use an alias, say
>> Alias /bottomframecontent /var/www/htdocs/abc/def
>> Here's global.html with a little Javascript to load the frames.
>> global.html
>> -----------
>> <html><head>
>> <script>
>> var loadFrames = function(){
>>      var viewFile ='?', '');
>>     document.getElementById('topframe').src =
>> "/perlResponseHandler?arg=" + viewFile;
>>      document.getElementById('bottomframe').src =
>> "/bottomframecontent/" + viewFile + ".html";
>> };
>> window.onload = loadFrames;
>> </script>
>> </head>
>> <frameset rows="100, *">
>>     <frame name="topframe" src="">
>>     <frame id="bottomframe" src="">
>> </frameset>
>> </html>
>> ------------
>> On 11/12/2012 3:42 PM, André Warnier wrote:
>>> 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 my "" URI was an oversimplification for the sake of this
>>> post.  The real URI for that first frame is more complicated to
>>> generate, and beyond what I can do with mod_rewrite et al.
>>> But second, I just realised that I cannot do things the way I explain
>>> below anyway, because inside a <frame> tag, you cannot put content. You
>>> can only use <frame src="..URI..">.
>>> So basically, my skeleton ResponseHandler works as I expected and does
>>> create the <frameset> document that I wanted and returns it, but that
>>> document is invalid html.
>>> Shucks. Back to the drawing board.
>>> Which now creates another issue :
>>> I could create instead a document like :
>>> <html>
>>> <head></head>
>>> <frameset rows="100,*">
>>>    <frame name="topframe" src="/cgi-bin/" />
>>>    <frame name="bottomframe" src=/abc/def/ghi.html">
>>> </frameset>
>>> </html>
>>> but.. the URI of the request for the second frame would trigger my
>>> ResponseHandler again, and I'd be stuck in a forever-loop of embedded
>>> frames, fractal-like.
>>> So now I am going to re-read your suggestions below, and see if I can
>>> figure out something along those lines which does not force me to edit
>>> and/or rename all the pages.
>>> Maybe instead of generating the second frame as
>>>    <frame name="bottomframe" src=/abc/def/ghi.html">
>>> I can instead generate it as
>>>    <frame name="bottomframe" src=/abc/def/ghi.html.perl">
>>> and then detect this in the Handler, change the $r->uri back to the
>>> correct one, and let Apache's default handler serve it by returning
>>> DECLINED.  I'll try that.
>>> Thanks for helping me think.
>>> gAzZaLi wrote:
>>>> 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 and the second frame with the static html file?
>>>> If you have control over the creation of the request URLs, you could
>>>> also have them come in as say, "show.html?ghi", which will be a
>>>> frameset html file which works as above and not have Apache do any
>>>> extra work.
>>>> In each case, your mod_perl handler would be simpler and deal only
>>>> with responding to the value of arg.
>>>> Of course you may have already considered and rejected these ideas and
>>>> I'm missing the point entirely.
>>>> On 11/12/2012 9:19 AM, André Warnier wrote:
>>>>> 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 by "mangling" the original
>>>>> request URL somewhat.
>>>>> - in the 2d frame, the content of the HTML file corresponding to the
>>>>> original request URI.
>>>>> For example, if the original request URI was something like :
>>>>> "/abc/def/ghi.html", then
>>>>>    - the top frame should contain the (html) output of a request to
>>>>> "/cgi-bin/"
>>>>>    - the bottom frame should contain the content of the
>>>>> originally-requested "/abc/def/ghi.html" URI (which is a static file).
>>>>> I am thinking of doing this by :
>>>>> - creating a mod_perl ResponseHandler
>>>>> - having this response handler make a first sub-request to the
>>>>> "/cgi-bin/" URI, grabbing the content of the response
>>>>> to that sub-request, and insert it into the first <frame> of the
>>>>> output
>>>>> <frameset> document.
>>>>> - having the response handler do a lookup_uri of the original URI, get
>>>>> the resulting filename, reading the file and insert its content
>>>>> into the
>>>>> second <frame> of the output <frameset> document.
>>>>> My 1st question is : is the above a valid plan, or is there something
>>>>> fundamentally wrong with this approach ?
>>>>> My 2d question is : looking at the Apache2::SubRequest
>>>>> documentation, I
>>>>> do not see a clear way of getting the response content of a
>>>>> subrequest.
>>>>> For example, the run() method explanation seems to indicate that the
>>>>> response content is sent directly to the client.
>>>>> Am I missing something ?
>>>>> TIA

View raw message