Ok I've got forensic logging going and using that and looking at the
correct error log (I was looking at the wrong file previously - grr!!) I'm
starting to get an idea about what is going on.
The forensic logs show that the request for the image is indeed being
received, but the error logs show:
Target WSGI script not found or unable to stat:
/myserver/usr/local/apache/wsgi-practice-scripts/images.wsgi
So it looks like server translates the path using WSGIScriptAliasMatch and
looks for wsgi script of that name, which it can't find so does not forward
the request (I can't say the documentation doesn't warn you about this
WSGIScriptAliasMatch - starting to understand why). Clearly the url of
every request is passed through the alias (obvious now, but my line of
though wasn't running that way when I put it in) and is resolving to an
invalid wsgi file.
In the ('broken') case where I type /tst the requst url for the image is
/images/open-ocean-wave-stephen-jorgensen.jpg
In the ('working') case where I type /tst/ the requst url for the image is
/tst/images/open-ocean-wave-stephen-jorgensen.jpg
So from this I infer that apache translates the url path typed in using
WSGIScriptAliasMatch and assumes the (translated) root 'directory' of the
uri is the path to the wsgi application (ignoring the rest of the uri, but
passing it as the uri in the request). Is that correct ?
Understanding this much I can resolve the problem in various ways -
specifying more specific alias rules (indeed ^/(.*?)(/|$) seems to work),
always including the root application name in url paths, plus, no doubt
several other solutions.
Thank you very much for your help on this.
However I'm still not entirely clear what apache does with the request
paths and for completion was wandering if any one could answer any of the
following questions:
With WSGIDaemonProcess does apache expect every request to resolve to a
wsgi script application (i.e apache does nothing to try and serve the file
in a different way if it is not a path to a valid application, so
/path/to/static/file.html will not work even if it exists (because it is
not a wsgi app))?
Once the path is translated how is the check for the existence of the
script done ?
Does the wsgi application have to have a .wsgi extension for apache to
recognise it a wsgi application ? Or can it have any name ?
If the url resolves to a valid application path, i.e as long as
/xxx/any/old/path after being passed through the alias ends up as
'/valid/path/to/xxx.wsgi/any/old/path' (as mentioned apache seems to simply
to take the root (/valid/path/to/xxx.wsgi) for the script name) the request
gets passed to the application regardless of the validity of any of the
paths I see in the apps request environment (PATH_INFO, REQUEST_URI,
PATH_INFO, PATH_TRANSLATED)?
On Monday, February 5, 2018 at 10:38:26 PM UTC, Graham Dumpleton wrote:
> Instead of:
>
> /myserver/usr/local/apache/htdocs/images
>
> try putting it in the directory:
>
> /myserver/usr/local/apache/htdocs/wsgi-practice-scripts/images
>
> Because you have:
>
> '<div style="background-image: url(images/myimage.jpg)">'
>
> it will resolve as a relative path to the page that is used in, thus:
>
> /wsgi-practice-scripts/images/myimage.jpg
>
> This is actually bad because if you do the same thing in a different
> script, you will need to create a separate copy for it.
>
> You would be better off using a something that generates an absolute path
> of:
>
> /images/myimage.jpg
>
> which means it should then be found at:
>
> /myserver/usr/local/apache/htdocs/images
>
> Graham
>
> On 6 Feb 2018, at 4:04 am, Larry Cotton <larry....@gmail.com <javascript:>>
> wrote:
>
> Hi
>
>
> Because I was not 100% sure where the server would expect it to be I
> actually have the image in two places, the root of the path specified by
> the WSGIScriptAliasMatch directive and in DocumentRoot:
>
> /myserver/usr/local/apache/wsgi-practice-scripts/images
> /myserver/usr/local/apache/htdocs/images
>
> Thinking the mismatch between DocumentRoot and WSGIScriptAliasMatch as
> well as using the default port for the VirtualHost may be confusing things
> I have changed the VirtualHost to using a different port (8085) and setting
> DocumentRoot to /myserver/usr/local/apache/wsgi-practice-scripts, but I
> still see the same behaviour.
>
> I notice from the request headers that when a directory is specified the
> path information is translated to a fully-qualified file name, not sure
> what the server does with the path info, but may be that is significant.
>
> I have built and installed the forensic logging module and when I get time
> I'll try to use it to have a look at requests more closely.
>
> On Friday, February 2, 2018 at 10:29:35 PM UTC, Graham Dumpleton wrote:
>
>> In what directory is myimage.jpg? Give full path name.
>>
>> Graham
>>
>> On 3 Feb 2018, at 4:14 am, Larry Cotton <larry....@gmail.com> wrote:
>>
>> Hi
>>
>> Thank you for your reply.
>>
>> I was naively thinking that because I did not see a request arrive it was
>> not sent by the browser, but of course it is probably being filtered out by
>> apache. I have included a summary of the apache configuration I am using in
>> case there is anything obvious there you can see, but I guess I really need
>> to gen up on what apache does before the requests are handed to the
>> mod_wsgi app. A quick google suggests the forensic logging module
>> (mod_log_forensic) allows logging of requests before and after processing -
>> looks like this would help.
>>
>> DocumentRoot "/myserver/usr/local/apache/htdocs"
>>
>> <Directory "/myserver/usr/local/apache/htdocs">
>>
>> Options Indexes FollowSymLinks
>>
>> AllowOverride None
>> Require all granted
>> </Directory>
>>
>> <IfModule dir_module>
>> DirectoryIndex index.html
>> </IfModule>
>>
>> <VirtualHost *:80>
>>
>> ServerName myserver.loc.comp.com
>> ServerAlias myserver
>> ServerAdmin ad...@gmail
>>
>> DocumentRoot "/myserver/usr/local/apache/htdocs"
>>
>> <Directory /myserver/usr/local/apache/htdocs>
>> Options Indexes FollowSymLinks
>> Require all granted
>> </Directory>
>>
>> WSGIDaemonProcess myserver processes=2 threads=15
>> display-name=%{GROUP} maximum-requests=10000
>> python-path=/myserver/usr/local/apache/wsgi-practice-scripts
>> WSGIProcessGroup myserver
>>
>> WSGIScriptAliasMatch ^/wsgipractice/([^/]+)
>> /myserver/usr/local/apache/wsgi-practice-scripts/$1.wsgi
>>
>> WSGIProcessGroup myserver
>>
>> <Directory /myserver/usr/local/apache/wsgi-practice-scripts>
>> Options Indexes FollowSymLinks
>> Require all granted
>> </Directory>
>>
>> </VirtualHost>
>>
>> On Thursday, February 1, 2018 at 11:02:29 AM UTC, Graham Dumpleton wrote:
>>
>>> How are you configuring Apache for mod_wsgi?
>>>
>>> Your code works, so the problem is likely how you are setting up the
>>> serving of the static file by Apache.
>>>
>>> Graham
>>>
>>> On 1 Feb 2018, at 9:14 pm, Larry Cotton <larry....@gmail.com> wrote:
>>>
>>> Hi
>>>
>>> Thank you for the reply.
>>>
>>> One of the reasons I am using mod_wsgi is to be able to understand a bit
>>> more about what goes on underneath.
>>>
>>> Thus far I have not had too many problems with mod_wsgi - the tutorials
>>> give information both on logging requests/responses and debugging the
>>> pythonry, so I am happy to go with it at the moment. If I get in to real
>>> difficulty I will take a step back.
>>>
>>> I already have a mass of stuff using cherrypy (which I understand has a
>>> hook for mod_wsgi, though I have not tried it yet), does Flask do
>>> anything different from CherryPy ?
>>>
>>>
>>> On Wednesday, January 31, 2018 at 2:11:12 PM UTC, Larry Cotton wrote:
>>>
>>>> Hi
>>>> System Info:
>>>>
>>>> # cat /etc/redhat-release
>>>> Red Hat Enterprise Linux Server release 6.4 (Santiago)
>>>>
>>>> # httpd -v
>>>> Server version: Apache/2.4.25 (Unix)
>>>> Server built: Jun 27 2017 16:23:25
>>>>
>>>> # python --version
>>>> Python 2.7.11
>>>>
>>>> -------------------------------------------------
>>>>
>>>> I have set up apache + mod_wsgi and have done some playing with it to
>>>> help get some understanding of how client and server interact.
>>>>
>>>> I am new to mod_wsgi and have not yet used it in anger, but the simple
>>>> apps I have written seem to be working ok.
>>>>
>>>> However there is something I would like to understand regarding how the
>>>> browser decides when to render a page.
>>>>
>>>> In the simple application below(tst1.wsgi) below I generate a simple
>>>> html page that contains an image, logging the REQUEST_URI
>>>> for each request.
>>>>
>>>> If, in the browser, I type the url <myserver>/wsgipractice/tst1/index
>>>> the browser attempts to fully render the page and puts in a second request
>>>> to get the image. The log output containing the REQUEST_URIs looks like:
>>>> /wsgipractice/tst1/index
>>>> /wsgipractice/tst1/images/myimage.jpg
>>>>
>>>> If, however, I type only the root url in the browser:
>>>> <myserver>/wsgipractice/tst1 the browser does not seem to attempt to
>>>> render
>>>> the html page. No second request is put in to fetch the image. The log
>>>> output containing the REQUEST_URIs looks like:
>>>> /wsgipractice/tst1
>>>>
>>>> It does not seem to matter what comes after tst1 in the url (I can type
>>>> in tst1/bob, or even simply terminate with separator: tst1/).
>>>>
>>>> Does anyone know what it is that triggers the browser to fully (or not)
>>>> render a page ?
>>>>
>>>>
>>>> tst1.wsgi
>>>> ----------
>>>> import os
>>>>
>>>> def get_page(environ, mime_type):
>>>>
>>>> html_str = \
>>>> ('<html><body>'
>>>> '<center><p style="font-weight:bold;">LARRY HOME</p></center>'
>>>> '<div style="background-image: url(images/myimage.jpg)">'
>>>> '<a href="http://google.com";>'
>>>> '<div>Home</div></a>'
>>>> '</div>'
>>>> '<br><p>Body</p><br></body></html>')
>>>>
>>>> return html_str, mime_type
>>>>
>>>> def application(environ, start_response):
>>>>
>>>> status = '200 OK'
>>>>
>>>> output = u''
>>>>
>>>> log_file = open(('/logs/tstpagegen.log'), 'a')
>>>>
>>>> log_file.write(environ['REQUEST_URI'] + '\n')
>>>>
>>>> log_file.close()
>>>>
>>>> output, mime_type = get_page(environ, 'text/html')
>>>>
>>>> response_headers = [('Content-type', mime_type),
>>>> ('Content-Length', str(len(output)))]
>>>>
>>>> start_response(status, response_headers)
>>>>
>>>> return [output]
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "modwsgi" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to modwsgi+u...@googlegroups.com.
>>> To post to this group, send email to mod...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/modwsgi.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "modwsgi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to modwsgi+u...@googlegroups.com.
>> To post to this group, send email to mod...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/modwsgi.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to modwsgi+u...@googlegroups.com <javascript:>.
> To post to this group, send email to mod...@googlegroups.com <javascript:>
> .
> Visit this group at https://groups.google.com/group/modwsgi.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to modwsgi+unsubscr...@googlegroups.com.
To post to this group, send email to modwsgi@googlegroups.com.
Visit this group at https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
