none
[Python][Web Apps] Selecting Python Version 3.4 breaks static file serving RRS feed

  • Question

  • If I leave "PYTHON VERSION" as OFF, then my application works fine; however if I change the Azure dashboard setting to select PYTHON VERSION 3.4 (or 2.7), then static files stop being served (/static route).

    I know this is because of some web.config magic, but I thought this should be handled for me without having to supply my own web.config file.

    The only way I have found is to provide my own /static route in my application, but this is inefficient.

    Can anyone tell me how to get around this please?

    Thanks.

    PS. I use PTVS and VS2013 for this Python application development environment.



    Dazure



    Sunday, October 11, 2015 6:27 PM

Answers

  • We are looking at options to address the initial issue. As it stands, the guidance is to not use the portal option to pick the Python, as it is problematic.

    David

    • Marked as answer by dfreer1 Tuesday, October 13, 2015 6:22 PM
    Tuesday, October 13, 2015 5:21 PM

All replies

  • hi Dfreer1,

    Generally, we should set the corresponding python version on Azure Web App service. From your description, it seems that you need reconfigure the Static file rules.

    Static files will be handled by the web server directly, without going through Python code, for improved performance, for example,

    <rewrite>
          <rules>
            <rule name="Static Files" stopProcessing="true">
              <conditions>
                <add input="true" pattern="false" />
              </conditions>
            </rule>
            <rule name="Configure Python" stopProcessing="true">
              <match url="(.*)" ignoreCase="false" />
              <conditions>
                <add input="{REQUEST_URI}" pattern="^/static/.*" ignoreCase="true" negate="true" />
              </conditions>
              <action type="Rewrite" url="handler.fcgi/{R:1}" appendQueryString="true" />
            </rule>
          </rules>
        </rewrite>
    
    This means that a request for http://pythonapp.azurewebsites.net/static/site.css will serve the file on disk at \static\site.css.

    Could you pleas share your configuration settings for our further support? Looking forward to having your feedback.

    Regards,

    Will


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, October 12, 2015 7:40 AM
    Moderator
  • Thanks for your reply Will.

    Yes, the settings you have shown appear in the 'automagically' generated web.config (using VS deployment script downloaded from Azure) - and this works fine (ie. server handles static files) - HOWEVER, if I change the setting in Azure for this web app to select 'Python Version' 3.4 instead of 'Off' then this stops working.

    Are you saying I must supply a web.config myself to make this work? I thought this should be handled for me without having to fiddle about with web.config settings myself?

    I used the VS2013 Python Bottle template to create the project, and used the Azure deployment script to publish. What other configuration settings can I provide to help?

    I appreciate your help.


    Dazure


    • Edited by dfreer1 Monday, October 12, 2015 8:15 AM spelling mistake
    Monday, October 12, 2015 8:15 AM
  • I thought re-importing the publish profile to VS would fix this but it didn't.

    The web.config is supposed to be auto-generated, but seems to fail when I set Python Version to anything but 'Off'


    Dazure

    Monday, October 12, 2015 3:42 PM
  • Here is the system.webServer section of the autogenerated web.config (from DebugConsole):

      <system.webServer>
        <modules runAllManagedModulesForAllRequests="true" />
        <handlers>
          <add name="Python FastCGI" path="handler.fcgi" verb="*" modules="FastCgiModule" scriptProcessor="D:\Python34\python.exe|D:\Python34\Scripts\wfastcgi.py" resourceType="Unspecified" requireAccess="Script" />
        </handlers>
        <rewrite>
          <rules>
            <rule name="Static Files" stopProcessing="true">
              <conditions>
                <add input="true" pattern="false" />
              </conditions>
            </rule>
            <rule name="Configure Python" stopProcessing="true">
              <match url="(.*)" ignoreCase="false" />
              <conditions>
                <add input="{REQUEST_URI}" pattern="^/static/.*" ignoreCase="true" negate="true" />
              </conditions>
              <action type="Rewrite" url="handler.fcgi/{R:1}" appendQueryString="true" />
            </rule>
          </rules>
        </rewrite>
      </system.webServer>


    Dazure

    Monday, October 12, 2015 3:50 PM
  • Where are you seeing this auto-generated config? If you take a fresh new app and turn on Python 3.4, you should see the following web.config getting generated in your d:\home\site\wwwroot folder (use Kudu Console to see it):

    <configuration>
      <appSettings>
        <add key="pythonpath" value="%SystemDrive%\home\site\wwwroot" />
        <add key="WSGI_HANDLER" value="hostingstart-python.application" />
      </appSettings>
    </configuration>
    

    The idea is that this is just a starter file. You'd need to download it and modify it to fit your needs (e.g. adding static file handling), and then deploy it with the rest of your files.

    Monday, October 12, 2015 4:41 PM
  • Also, please see this article which has lots of details on getting started with Python on Azure Web Apps.
    Monday, October 12, 2015 4:45 PM
  • Where are you seeing this auto-generated config? If you take a fresh new app and turn on Python 3.4, you should see the following web.config getting generated in your d:\home\site\wwwroot folder (use Kudu Console to see it):

    <configuration>
      <appSettings>
        <add key="pythonpath" value="%SystemDrive%\home\site\wwwroot" />
        <add key="WSGI_HANDLER" value="hostingstart-python.application" />
      </appSettings>
    </configuration>

    The idea is that this is just a starter file. You'd need to download it and modify it to fit your needs (e.g. adding static file handling), and then deploy it with the rest of your files.

    Thanks David.

    Yes, Kudo console is where I was looking at web.config.

    The web.config you show is the one created when you initially create a web app; however as soon as you build the solution in VS2013, a web.config is auto generated and after publishing, this web.config is seen in Kudo console.

    When you view web.config in solution, there is the following comment at the top of the file:

    <!-- Generated web.config for Microsoft Azure. Remove this comment to prevent
         modifications being overwritten when publishing the project.
    -->

    This works nicely UNTIL you change the Python Version to 3.4 - then even though web.config still shows the "Static Files" rule - it does not serve static files. 

    Just to make sure this was nothing to do with my current project I started a brand new clean demo one like this:

    1. Create new Azure web app (custom, Bottle Python)

    2. Leave all configuration settings as is.

    3. In VS2013 create new project (Bottle Python template).

    4. In Azure dashboard 'Download the publish profile'

    5. In VS2013 import this profile, and 'Publish'

    6. Runs nicely from Azure ( ..azurewebsites.net)

    7. NOW in Azure Configure, change PYTHON VERSION to 3.4, save settings

    8. Now when run from Azure, it does not work (static .css etc not served)

    So a web.config is being deployed (albeit an auto generated one from VS) but still fails.

    Any ideas?

    Thanks.


    Dazure


    • Edited by dfreer1 Monday, October 12, 2015 6:50 PM spelling
    Monday, October 12, 2015 6:27 PM
  • Also, please see this article which has lots of details on getting started with Python on Azure Web Apps.
    Nice article, but it doesn't seem to mention publishing from Visual Studio using imported publish profile.

    Dazure

    Monday, October 12, 2015 6:33 PM
  • I this scenario, I don't think you need to set the Python version in Azure at all, as you are already doing this from the web.config you are publishing.
    Monday, October 12, 2015 7:02 PM
  • I this scenario, I don't think you need to set the Python version in Azure at all, as you are already doing this from the web.config you are publishing.

    Yes, I left it alone at the start of the project because it didn't work, but now I come to run "webjobs" with this app, and I have to set this Python Version to 3.4, else it uses 2.7 :-)

    Is there another way of forcing the webjob script to use Python 3.4? I'd be happy to workaround it if possible.

    Thanks.


    Dazure

    Monday, October 12, 2015 7:31 PM
  • I see. So I think you do need to set it to 3.4 in the portal.

    In your step 7 and 8 before, does the app start working again if you redeploy it from VS after setting it to 3.4 in Azure? i.e. maybe the act of setting it to 3.4 is messing up some files, but a deployment would fix it up.

    Monday, October 12, 2015 8:00 PM
  • I see. So I think you do need to set it to 3.4 in the portal.

    In your step 7 and 8 before, does the app start working again if you redeploy it from VS after setting it to 3.4 in Azure? i.e. maybe the act of setting it to 3.4 is messing up some files, but a deployment would fix it up.

    Thanks for this suggestion - I just tried this on the demo project I set up - and unfortunately, no, redeploying it does not fix it (see http://easycheck5.azurewebsites.net/)

    See see http://easycheck4.azurewebsites.net/ to see how it should look (I deplyed exact same demo project here - only difference is PYTHON VERSION is OFF)

    I wonder if it is something to do with having to supply a file called web.3.4.config which gets copied to web.config? I think I read somewhere about this?

    I appreciate your help.


    Dazure


    • Edited by dfreer1 Monday, October 12, 2015 8:15 PM additional information
    Monday, October 12, 2015 8:09 PM
  • Yes, I see that the portal option messes things up.

    Alternate workaround for your WebJob:

    • Create a run.cmd file next to your Python Web
    • In there, just add line line that has: D:\Python34\python.exe yourscript.py

    This way you explicitly pick the version without relying on what's on the path.

    Tuesday, October 13, 2015 12:56 AM
  • Yes, I see that the portal option messes things up.

    Alternate workaround for your WebJob:

    • Create a run.cmd file next to your Python Web
    • In there, just add line line that has: D:\Python34\python.exe yourscript.py

    This way you explicitly pick the version without relying on what's on the path.

    This sounds good. I'll try it. Thanks for this.

    What about the original problem? How do we get it fixed? Is there somewhere (else) to report it, or do we just have to 'hope and pray' ?


    Dazure

    Tuesday, October 13, 2015 9:10 AM
  • We are looking at options to address the initial issue. As it stands, the guidance is to not use the portal option to pick the Python, as it is problematic.

    David

    • Marked as answer by dfreer1 Tuesday, October 13, 2015 6:22 PM
    Tuesday, October 13, 2015 5:21 PM
  • Yes, I see that the portal option messes things up.

    Alternate workaround for your WebJob:

    • Create a run.cmd file next to your Python Web
    • In there, just add line line that has: D:\Python34\python.exe yourscript.py

    This way you explicitly pick the version without relying on what's on the path.

    This run.cmd works nicely for the webjobs workaround.

    Thank you very much for this.


    Dazure

    Tuesday, October 13, 2015 6:22 PM