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.cot...@gmail.com> 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
>> <http://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 <http://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
>>> <http://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 <http://googlegroups.com/>.
>>> To post to this group, send email to mod...@ <>googlegroups.com
>>> <http://googlegroups.com/>.
>>> Visit this group at https://groups.google.com/group/modwsgi
>>> <https://groups.google.com/group/modwsgi>.
>>> For more options, visit https://groups.google.com/d/optout
>>> <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
>> <https://groups.google.com/group/modwsgi>.
>> For more options, visit https://groups.google.com/d/optout
>> <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
> <mailto:modwsgi+unsubscr...@googlegroups.com>.
> To post to this group, send email to modwsgi@googlegroups.com
> <mailto:modwsgi@googlegroups.com>.
> Visit this group at https://groups.google.com/group/modwsgi
> <https://groups.google.com/group/modwsgi>.
> For more options, visit https://groups.google.com/d/optout
> <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.
