Larivact · January 31, 2025 08:39 · Mar 17, 2017 · Mar 17, 2017 · Mar 17, 2017 · Mar 17, 2017
diff --git a/flask_script_name.md b/flask_script_name.md
@@ -11,7 +11,7 @@ The initial portion of the request URL's "path" that corresponds to the applicat
 **PATH_INFO**   
 The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash.
 
-Flask's routing and `url_for` are provided by Werkzeug. Werkzeug's routing operates on `PATH_INFO` and its `url_for` function prepends `SCRIPT_NAME`.
+Flask's routing and `url_for` are provided by [Werkzeug](http://werkzeug.pocoo.org/). Werkzeug's routing operates on `PATH_INFO` and its `url_for` function prepends `SCRIPT_NAME`.
 
 ## Conclusion
 
@@ -24,7 +24,7 @@ gunicorn -e SCRIPT_NAME=/my-app my_app:app
 ```
 
 **With Flask's dev server**  
-Flask's builtin development server [`app.run()`](http://flask.pocoo.org/docs/0.10/api/#flask.Flask.run) uses [`werkzeug.serving.run_simple()`](http://werkzeug.pocoo.org/docs/0.11/serving/#werkzeug.serving.run_simple). In order to use the convenient debugging and reloading features while still serving the site under a `SCRIPT_NAME` you would have to use a WSGI middleware that sets the `SCRIPT_NAME` and trims the `PATH_INFO`.
+Flask's builtin development server [`app.run()`](http://flask.pocoo.org/docs/api/#flask.Flask.run) uses [`werkzeug.serving.run_simple()`](http://werkzeug.pocoo.org/docs/serving/#werkzeug.serving.run_simple). In order to use the convenient debugging and reloading features while still serving the site under a `SCRIPT_NAME` you would have to use a WSGI middleware that sets the `SCRIPT_NAME` and trims the `PATH_INFO`.
 
 ```python
 from werkzeug.serving import run_simple

diff --git a/flask_script_name.md b/flask_script_name.md
@@ -1,9 +1,9 @@
 # Serving Flask under a subpath
 
-Your Flask app object implements the `__call__` method, which means it can be called like a regular function. 
-When a HTTP request comes in your WSGI container calls your app the `environ` dict and the `start_response` callable.
+Your Flask app object implements the `__call__` method, which means it can be called like a regular function.
+When your WSGI container receives a HTTP request it calls your app with the `environ` dict and the `start_response` callable.
 WSGI is specified in [PEP 0333](https://www.python.org/dev/peps/pep-0333/#environ-variables).
-The two relevant environ variables are :
+The two relevant environ variables are:
 
 **SCRIPT_NAME**  
 The initial portion of the request URL's "path" that corresponds to the application object, so that the application knows its virtual "location". This may be an empty string, if the application corresponds to the "root" of the server.

diff --git a/flask_script_name.md b/flask_script_name.md
@@ -1,19 +1,21 @@
 # Serving Flask under a subpath
 
 Your Flask app object implements the `__call__` method, which means it can be called like a regular function. 
-When a HTTP request comes in your WSGI container calls your app with the standard WSGI parameters `environ` and `start_response`.
-
-Flask's routing and `url_for` are provided by Werkzeug. Werkzeug correctly implements [PEP 0333](https://www.python.org/dev/peps/pep-0333/#environ-variables)'s description of the environ variables, which states:
+When a HTTP request comes in your WSGI container calls your app the `environ` dict and the `start_response` callable.
+WSGI is specified in [PEP 0333](https://www.python.org/dev/peps/pep-0333/#environ-variables).
+The two relevant environ variables are :
 
 **SCRIPT_NAME**  
 The initial portion of the request URL's "path" that corresponds to the application object, so that the application knows its virtual "location". This may be an empty string, if the application corresponds to the "root" of the server.
 
 **PATH_INFO**   
 The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash.
 
+Flask's routing and `url_for` are provided by Werkzeug. Werkzeug's routing operates on `PATH_INFO` and its `url_for` function prepends `SCRIPT_NAME`.
+
 ## Conclusion
 
-This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`. Werkzeug's routing operates on `PATH_INFO` and its `url_for` function prepends `SCRIPT_NAME`.
+This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`.
 
 **In production**  
 How you do this depends on your [deployment option](http://flask.pocoo.org/docs/deploying/). Eg. with [Gunicorn](http://gunicorn.org/) you can pass environment variables with `-e`.

diff --git a/flask_script_name.md b/flask_script_name.md
@@ -16,7 +16,7 @@ The remainder of the request URL's "path", designating the virtual "location" of
 This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`. Werkzeug's routing operates on `PATH_INFO` and its `url_for` function prepends `SCRIPT_NAME`.
 
 **In production**  
-How you do this depends on your chosen [deployment option](http://flask.pocoo.org/docs/0.10/deploying/#deployment). For example when using [gunicorn](http://gunicorn.org/) you do it like this:
+How you do this depends on your [deployment option](http://flask.pocoo.org/docs/deploying/). Eg. with [Gunicorn](http://gunicorn.org/) you can pass environment variables with `-e`.
 ```
 gunicorn -e SCRIPT_NAME=/my-app my_app:app
 ```

diff --git a/flask_script_name.md b/flask_script_name.md
@@ -1,6 +1,7 @@
-# Serving Flask under a sub path
+# Serving Flask under a subpath
 
-Your Flask app object implements the `__call__` method which means it can be called like a regular function. Your WSGI container needs access to your `app` "function", now when an HTTP request comes in the WSGI container calls our "app function" with the standard WSGI parameters `environ` and `start_response`.
+Your Flask app object implements the `__call__` method, which means it can be called like a regular function. 
+When a HTTP request comes in your WSGI container calls your app with the standard WSGI parameters `environ` and `start_response`.
 
 Flask's routing and `url_for` are provided by Werkzeug. Werkzeug correctly implements [PEP 0333](https://www.python.org/dev/peps/pep-0333/#environ-variables)'s description of the environ variables, which states:
 

diff --git a/flask_script_name.md b/flask_script_name.md
@@ -1,4 +1,4 @@
-#Serving Flask under a sub path
+# Serving Flask under a sub path
 
 Your Flask app object implements the `__call__` method which means it can be called like a regular function. Your WSGI container needs access to your `app` "function", now when an HTTP request comes in the WSGI container calls our "app function" with the standard WSGI parameters `environ` and `start_response`.
 
@@ -10,7 +10,7 @@ The initial portion of the request URL's "path" that corresponds to the applicat
 **PATH_INFO**   
 The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash.
 
-##Conclusion
+## Conclusion
 
 This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`. Werkzeug's routing operates on `PATH_INFO` and its `url_for` function prepends `SCRIPT_NAME`.
 

diff --git a/flask_script_name.md b/flask_script_name.md
@@ -28,18 +28,19 @@ from werkzeug.serving import run_simple
 from my_app import app
 
 class FixScriptName(object):
-     def __init__(self, app):
-         self.app = app
-
-     def __call__(self, environ, start_response):
-	SCRIPT_NAME = '/my-app'
-	if environ['PATH_INFO'].startswith(SCRIPT_NAME):
-	        environ['PATH_INFO'] = environ['PATH_INFO'][len(SCRIPT_NAME):]
-	        environ['SCRIPT_NAME'] = SCRIPT_NAME
-	        return self.app(environ, start_response)
-	else:
-		start_response('404', [('Content-Type', 'text/plain')])
-		return ["This doesn't get served by your FixScriptName middleware.".encode()]
+	def __init__(self, app):
+		self.app = app
+
+	def __call__(self, environ, start_response):
+		SCRIPT_NAME = '/my-app'
+
+		if environ['PATH_INFO'].startswith(SCRIPT_NAME):
+			environ['PATH_INFO'] = environ['PATH_INFO'][len(SCRIPT_NAME):]
+			environ['SCRIPT_NAME'] = SCRIPT_NAME
+			return self.app(environ, start_response)
+		else:
+			start_response('404', [('Content-Type', 'text/plain')])
+			return ["This doesn't get served by your FixScriptName middleware.".encode()]
 
 app = FixScriptName(app)
 

diff --git a/flask_script_name.md b/flask_script_name.md
@@ -32,10 +32,14 @@ class FixScriptName(object):
          self.app = app
 
      def __call__(self, environ, start_response):
-		SCRIPT_NAME = '/my-app'
-        environ['PATH_INFO'] = environ['PATH_INFO'][len(SCRIPT_NAME):]
-        environ['SCRIPT_NAME'] = SCRIPT_NAME
-        return self.app(environ, start_response)
+	SCRIPT_NAME = '/my-app'
+	if environ['PATH_INFO'].startswith(SCRIPT_NAME):
+	        environ['PATH_INFO'] = environ['PATH_INFO'][len(SCRIPT_NAME):]
+	        environ['SCRIPT_NAME'] = SCRIPT_NAME
+	        return self.app(environ, start_response)
+	else:
+		start_response('404', [('Content-Type', 'text/plain')])
+		return ["This doesn't get served by your FixScriptName middleware.".encode()]
 
 app = FixScriptName(app)
 

diff --git a/flask_script_name.md b/flask_script_name.md
@@ -32,7 +32,7 @@ class FixScriptName(object):
          self.app = app
 
      def __call__(self, environ, start_response):
-		SCRIPT_NAME = 'my-app'
+		SCRIPT_NAME = '/my-app'
         environ['PATH_INFO'] = environ['PATH_INFO'][len(SCRIPT_NAME):]
         environ['SCRIPT_NAME'] = SCRIPT_NAME
         return self.app(environ, start_response)

diff --git a/flask_script_name.md b/flask_script_name.md
@@ -15,7 +15,10 @@ The remainder of the request URL's "path", designating the virtual "location" of
 This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`. Werkzeug's routing operates on `PATH_INFO` and its `url_for` function prepends `SCRIPT_NAME`.
 
 **In production**  
-How you do this depends on your chosen [deployment option](http://flask.pocoo.org/docs/0.10/deploying/#deployment). For example when using [gunicorn](http://gunicorn.org/) you do it like this: `gunicorn -e SCRIPT_NAME=/my-app my_app:app`.
+How you do this depends on your chosen [deployment option](http://flask.pocoo.org/docs/0.10/deploying/#deployment). For example when using [gunicorn](http://gunicorn.org/) you do it like this:
+```
+gunicorn -e SCRIPT_NAME=/my-app my_app:app
+```
 
 **With Flask's dev server**  
 Flask's builtin development server [`app.run()`](http://flask.pocoo.org/docs/0.10/api/#flask.Flask.run) uses [`werkzeug.serving.run_simple()`](http://werkzeug.pocoo.org/docs/0.11/serving/#werkzeug.serving.run_simple). In order to use the convenient debugging and reloading features while still serving the site under a `SCRIPT_NAME` you would have to use a WSGI middleware that sets the `SCRIPT_NAME` and trims the `PATH_INFO`.

diff --git a/flask_script_name.md b/flask_script_name.md
@@ -14,9 +14,10 @@ The remainder of the request URL's "path", designating the virtual "location" of
 
 This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`. Werkzeug's routing operates on `PATH_INFO` and its `url_for` function prepends `SCRIPT_NAME`.
 
-How you do this depends on which [deployment option](http://flask.pocoo.org/docs/0.10/deploying/#deployment) you choose. For example when using [gunicorn](http://gunicorn.org/) you do it like this: `gunicorn -e SCRIPT_NAME=/my-app my_app:app`.
+**In production**  
+How you do this depends on your chosen [deployment option](http://flask.pocoo.org/docs/0.10/deploying/#deployment). For example when using [gunicorn](http://gunicorn.org/) you do it like this: `gunicorn -e SCRIPT_NAME=/my-app my_app:app`.
 
-**Using Flask's dev server**  
+**With Flask's dev server**  
 Flask's builtin development server [`app.run()`](http://flask.pocoo.org/docs/0.10/api/#flask.Flask.run) uses [`werkzeug.serving.run_simple()`](http://werkzeug.pocoo.org/docs/0.11/serving/#werkzeug.serving.run_simple). In order to use the convenient debugging and reloading features while still serving the site under a `SCRIPT_NAME` you would have to use a WSGI middleware that sets the `SCRIPT_NAME` and trims the `PATH_INFO`.
 
 ```python

diff --git a/flask_script_name.md b/flask_script_name.md
@@ -17,7 +17,7 @@ This means that if your application isn't located at the root of your server but
 How you do this depends on which [deployment option](http://flask.pocoo.org/docs/0.10/deploying/#deployment) you choose. For example when using [gunicorn](http://gunicorn.org/) you do it like this: `gunicorn -e SCRIPT_NAME=/my-app my_app:app`.
 
 **Using Flask's dev server**  
-Flask's builtin development server [`app.run()`](http://flask.pocoo.org/docs/0.10/api/#flask.Flask.run) uses `werkzeug.serving.run_simple()`. In order to use the convenient debugging and reloading features while still serving the site under a `SCRIPT_NAME` you would have to use a WSGI middleware that sets the `SCRIPT_NAME` and trims the `PATH_INFO`.
+Flask's builtin development server [`app.run()`](http://flask.pocoo.org/docs/0.10/api/#flask.Flask.run) uses [`werkzeug.serving.run_simple()`](http://werkzeug.pocoo.org/docs/0.11/serving/#werkzeug.serving.run_simple). In order to use the convenient debugging and reloading features while still serving the site under a `SCRIPT_NAME` you would have to use a WSGI middleware that sets the `SCRIPT_NAME` and trims the `PATH_INFO`.
 
 ```python
 from werkzeug.serving import run_simple

diff --git a/flask_script_name.md b/flask_script_name.md
@@ -17,7 +17,7 @@ This means that if your application isn't located at the root of your server but
 How you do this depends on which [deployment option](http://flask.pocoo.org/docs/0.10/deploying/#deployment) you choose. For example when using [gunicorn](http://gunicorn.org/) you do it like this: `gunicorn -e SCRIPT_NAME=/my-app my_app:app`.
 
 **Using Flask's dev server**  
-Flask's builtin development server [`app.run()`](http://flask.pocoo.org/docs/0.10/api/#flask.Flask.run) uses `werkzeug.serving.run_simple()`. In order to use the convenient debugging and reloading features while still serving the site under a `SCRIPT_NAME` you would have to use a WSGI middleware that sets the 'SCRIPT_NAME' and trims the 'PATH_INFO'.
+Flask's builtin development server [`app.run()`](http://flask.pocoo.org/docs/0.10/api/#flask.Flask.run) uses `werkzeug.serving.run_simple()`. In order to use the convenient debugging and reloading features while still serving the site under a `SCRIPT_NAME` you would have to use a WSGI middleware that sets the `SCRIPT_NAME` and trims the `PATH_INFO`.
 
 ```python
 from werkzeug.serving import run_simple

diff --git a/flask_script_name.md b/flask_script_name.md
@@ -14,4 +14,26 @@ The remainder of the request URL's "path", designating the virtual "location" of
 
 This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`. Werkzeug's routing operates on `PATH_INFO` and its `url_for` function prepends `SCRIPT_NAME`.
 
-How you do this depends on which [deployment option](http://flask.pocoo.org/docs/0.10/deploying/#deployment) you choose. For example when using [gunicorn](http://gunicorn.org/) you do it like this: `gunicorn -e SCRIPT_NAME=/my-app my_app:app`.
+How you do this depends on which [deployment option](http://flask.pocoo.org/docs/0.10/deploying/#deployment) you choose. For example when using [gunicorn](http://gunicorn.org/) you do it like this: `gunicorn -e SCRIPT_NAME=/my-app my_app:app`.
+
+**Using Flask's dev server**  
+Flask's builtin development server [`app.run()`](http://flask.pocoo.org/docs/0.10/api/#flask.Flask.run) uses `werkzeug.serving.run_simple()`. In order to use the convenient debugging and reloading features while still serving the site under a `SCRIPT_NAME` you would have to use a WSGI middleware that sets the 'SCRIPT_NAME' and trims the 'PATH_INFO'.
+
+```python
+from werkzeug.serving import run_simple
+from my_app import app
+
+class FixScriptName(object):
+     def __init__(self, app):
+         self.app = app
+
+     def __call__(self, environ, start_response):
+		SCRIPT_NAME = 'my-app'
+        environ['PATH_INFO'] = environ['PATH_INFO'][len(SCRIPT_NAME):]
+        environ['SCRIPT_NAME'] = SCRIPT_NAME
+        return self.app(environ, start_response)
+
+app = FixScriptName(app)
+
+run_simple('0.0.0.0', 5000, app, use_reloader=True)
+```
diff --git a/flask_script_name.md b/flask_script_name.md
@@ -10,6 +10,8 @@ The initial portion of the request URL's "path" that corresponds to the applicat
 **PATH_INFO**   
 The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash.
 
+##Conclusion
+
 This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`. Werkzeug's routing operates on `PATH_INFO` and its `url_for` function prepends `SCRIPT_NAME`.
 
 How you do this depends on which [deployment option](http://flask.pocoo.org/docs/0.10/deploying/#deployment) you choose. For example when using [gunicorn](http://gunicorn.org/) you do it like this: `gunicorn -e SCRIPT_NAME=/my-app my_app:app`.
diff --git a/flask_script_name.md b/flask_script_name.md
@@ -10,4 +10,6 @@ The initial portion of the request URL's "path" that corresponds to the applicat
 **PATH_INFO**   
 The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash.
 
-This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`. Werkzeug's routing operates on `PATH_INFO` and its `url_for` function prepends `SCRIPT_NAME`.
+This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`. Werkzeug's routing operates on `PATH_INFO` and its `url_for` function prepends `SCRIPT_NAME`.
+
+How you do this depends on which [deployment option](http://flask.pocoo.org/docs/0.10/deploying/#deployment) you choose. For example when using [gunicorn](http://gunicorn.org/) you do it like this: `gunicorn -e SCRIPT_NAME=/my-app my_app:app`.
diff --git a/flask_script_name.md b/flask_script_name.md
@@ -10,4 +10,4 @@ The initial portion of the request URL's "path" that corresponds to the applicat
 **PATH_INFO**   
 The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash.
 
-This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`. Werkzeug's routing operates on 'PATH_INFO' and its `url_for` function prepends `SCRIPT_NAME`.
+This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`. Werkzeug's routing operates on `PATH_INFO` and its `url_for` function prepends `SCRIPT_NAME`.
diff --git a/flask_script_name.md b/flask_script_name.md
@@ -2,7 +2,7 @@
 
 Your Flask app object implements the `__call__` method which means it can be called like a regular function. Your WSGI container needs access to your `app` "function", now when an HTTP request comes in the WSGI container calls our "app function" with the standard WSGI parameters `environ` and `start_response`.
 
-Flask's routing and `url_for` are provided by Werkzeug. Werkzeug correctly implements [PEP 0333](https://www.python.org/dev/peps/pep-0333/#environ-variables)'s description of the environ variables which states:
+Flask's routing and `url_for` are provided by Werkzeug. Werkzeug correctly implements [PEP 0333](https://www.python.org/dev/peps/pep-0333/#environ-variables)'s description of the environ variables, which states:
 
 **SCRIPT_NAME**  
 The initial portion of the request URL's "path" that corresponds to the application object, so that the application knows its virtual "location". This may be an empty string, if the application corresponds to the "root" of the server.

diff --git a/flask_script_name.md b/flask_script_name.md
@@ -10,4 +10,4 @@ The initial portion of the request URL's "path" that corresponds to the applicat
 **PATH_INFO**   
 The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash.
 
-This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container that the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`. Werkzeug's routing operates on 'PATH_INFO' and its `url_for` function prepends `SCRIPT_NAME`.
+This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`. Werkzeug's routing operates on 'PATH_INFO' and its `url_for` function prepends `SCRIPT_NAME`.
diff --git a/flask_script_name.md b/flask_script_name.md
@@ -5,7 +5,8 @@ Your Flask app object implements the `__call__` method which means it can be cal
 Flask's routing and `url_for` are provided by Werkzeug. Werkzeug correctly implements [PEP 0333](https://www.python.org/dev/peps/pep-0333/#environ-variables)'s description of the environ variables which states:
 
 **SCRIPT_NAME**  
-The initial portion of the request URL's "path" that corresponds to the application object, so that the application knows its virtual "location". This may be an empty string, if the application corresponds to the "root" of the server. 
+The initial portion of the request URL's "path" that corresponds to the application object, so that the application knows its virtual "location". This may be an empty string, if the application corresponds to the "root" of the server.
+
 **PATH_INFO**   
 The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash.
 

diff --git a/flask_script_name.md b/flask_script_name.md
@@ -4,9 +4,9 @@ Your Flask app object implements the `__call__` method which means it can be cal
 
 Flask's routing and `url_for` are provided by Werkzeug. Werkzeug correctly implements [PEP 0333](https://www.python.org/dev/peps/pep-0333/#environ-variables)'s description of the environ variables which states:
 
-**SCRIPT_NAME**
+**SCRIPT_NAME**  
 The initial portion of the request URL's "path" that corresponds to the application object, so that the application knows its virtual "location". This may be an empty string, if the application corresponds to the "root" of the server. 
-**PATH_INFO**
+**PATH_INFO**   
 The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash.
 
 This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container that the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`. Werkzeug's routing operates on 'PATH_INFO' and its `url_for` function prepends `SCRIPT_NAME`.
diff --git a/flask_script_name.md b/flask_script_name.md
@@ -1,4 +1,4 @@
-#Serving Flask under a different application root path
+#Serving Flask under a sub path
 
 Your Flask app object implements the `__call__` method which means it can be called like a regular function. Your WSGI container needs access to your `app` "function", now when an HTTP request comes in the WSGI container calls our "app function" with the standard WSGI parameters `environ` and `start_response`.
 

diff --git a/...nder_a_different_application_root_path.md → flask_script_name.md b/...nder_a_different_application_root_path.md → flask_script_name.md
@@ -1,3 +1,5 @@
+#Serving Flask under a different application root path
+
 Your Flask app object implements the `__call__` method which means it can be called like a regular function. Your WSGI container needs access to your `app` "function", now when an HTTP request comes in the WSGI container calls our "app function" with the standard WSGI parameters `environ` and `start_response`.
 
 Flask's routing and `url_for` are provided by Werkzeug. Werkzeug correctly implements [PEP 0333](https://www.python.org/dev/peps/pep-0333/#environ-variables)'s description of the environ variables which states:

diff --git a/serving_flask_under_a_different_application_root_path.md b/serving_flask_under_a_different_application_root_path.md
@@ -0,0 +1,10 @@
+Your Flask app object implements the `__call__` method which means it can be called like a regular function. Your WSGI container needs access to your `app` "function", now when an HTTP request comes in the WSGI container calls our "app function" with the standard WSGI parameters `environ` and `start_response`.
+
+Flask's routing and `url_for` are provided by Werkzeug. Werkzeug correctly implements [PEP 0333](https://www.python.org/dev/peps/pep-0333/#environ-variables)'s description of the environ variables which states:
+
+**SCRIPT_NAME**
+The initial portion of the request URL's "path" that corresponds to the application object, so that the application knows its virtual "location". This may be an empty string, if the application corresponds to the "root" of the server. 
+**PATH_INFO**
+The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash.
+
+This means that if your application isn't located at the root of your server but under a path you have to tell your WSGI container that the env `SCRIPT_NAME`. It will then split incoming request paths into `SCRIPT_NAME` and `PATH_INFO`. Werkzeug's routing operates on 'PATH_INFO' and its `url_for` function prepends `SCRIPT_NAME`.
No results found