Revert "drop the x- prefix from our custom headers"

This reverts commit 2b4c661.

Author: dbu

CHANGELOG.md

@@ -6,8 +6,6 @@ See also the [GitHub releases page](https://github.com/FriendsOfSymfony/FOSHttpC
 2.0.0 (unreleased)
 ------------------
 
-* Change all our custom headers to not use a `X-` prefix to comply with
-  [RFC 6648](http://tools.ietf.org/html/rfc6648#section-3).
 * Replace hard coupling on Guzzle HTTP client with HTTP adapter. You now need
   to explicitly specify the adapter you want, see [installation instructions]
   (http://foshttpcache.readthedocs.org/en/stable/installation.html)

doc/cache-invalidator.rst

@@ -148,9 +148,9 @@ You can also invalidate the cache based on any headers.
 Cache client implementations should fill up the headers to at least have the
 default headers always present to simplify the cache configuration rules.
 
-To invalidate on a custom header ``My-Header``, you would do::
+To invalidate on a custom header ``X-My-Header``, you would do::
 
-    $cacheInvalidator->invalidate(['My-Header' => 'my-value'])->flush();
+    $cacheInvalidator->invalidate(['X-My-Header' => 'my-value'])->flush();
 
 .. _flush:
 

doc/includes/custom-ttl.rst

@@ -12,6 +12,6 @@ the response to remove or reduce the ``s-maxage``. This is not a good solution
 however, as you start to duplicate your caching rule definitions.
 
 The solution to this issue provided here is to use a separate, different header
-called ``Reverse-Proxy-TTL`` that controls the TTL of the caching proxy to
+called ``X-Reverse-Proxy-TTL`` that controls the TTL of the caching proxy to
 keep ``s-maxage`` for other proxies. Because this is not a standard feature,
 you need to add configuration to your caching proxy.

doc/nginx-configuration.rst

@@ -43,7 +43,7 @@ Refresh
 If you want to invalidate cached objects by forcing a :term:`refresh`
 you have to use the built-in `proxy_cache_bypass <http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_bypass>`_
 directive. This directive defines conditions under which the response will not
-be taken from a cache. This library uses a custom HTTP header named ``Refresh``,
+be taken from a cache. This library uses a custom HTTP header named ``X-Refresh``,
 so add a line like the following to your config:
 
 .. literalinclude:: ../tests/Functional/Fixtures/nginx/fos.conf
@@ -55,9 +55,9 @@ so add a line like the following to your config:
 Debugging
 ~~~~~~~~~
 
-Configure your Nginx to set a custom header (`Cache`) that shows whether a
+Configure your Nginx to set a custom header (`X-Cache`) that shows whether a
 cache hit or miss occurred:
 
 .. code-block:: none
 
-    add_header Cache $upstream_cache_status;
+    add_header X-Cache $upstream_cache_status;

doc/proxy-clients.rst

@@ -102,7 +102,7 @@ include that port in the base URL::
 
 The other options for the Varnish client are:
 
-* ``tags_header`` (Cache-Tags): Allows you to change the HTTP header used for
+* ``tags_header`` (X-Cache-Tags): Allows you to change the HTTP header used for
   tagging. If you change this, make sure to use the correct header name in your
   :doc:`caching proxy configuration <proxy-configuration>`;
 * ``header_length`` (7500): Control the maximum header size when invalidating
@@ -113,7 +113,7 @@ A full example could look like this::
 
     $options = [
         'base_uri' => 'example.com',
-        'tags_header' => 'Custom-Tags-Header',
+        'tags_header' => 'X-Custom-Tags-Header',
         'header_length' => 4000,
     ];
 
@@ -223,7 +223,7 @@ You can specify HTTP headers as the second argument to ``purge()``.
 For instance::
 
     $client
-        ->purge('/some/path', ['Foo' => 'bar'])
+        ->purge('/some/path', ['X-Foo' => 'bar'])
         ->flush()
     ;
 

doc/response-tagging.rst

@@ -56,7 +56,7 @@ Before any content is sent out, you need to send the tag header_::
 Assume you sent four responses:
 
 +------------+-------------------------+
-| Response:  | ``Cache-Tags`` header:|
+| Response:  | ``X-Cache-Tags`` header:|
 +============+=========================+
 | ``/one``   | ``tag-one``             |
 +------------+-------------------------+

doc/symfony-cache-configuration.rst

@@ -191,7 +191,7 @@ options through the constructor:
 * **user_hash_header**: Name of the header the user context hash will be stored
   into. Must match the setup for the Vary header in the backend application.
 
-  **default**: ``User-Context-Hash``
+  **default**: ``X-User-Context-Hash``
 
 * **user_hash_uri**: Target URI used in the request for user context hash
   generation.
@@ -243,14 +243,14 @@ Custom TTL
 .. include:: includes/custom-ttl.rst
 
 The ``CustomTtlSubscriber`` looks at a specific header to determine the TTL,
-preferring that over ``s-maxage``. The default header is ``Reverse-Proxy-TTL``
+preferring that over ``s-maxage``. The default header is ``X-Reverse-Proxy-TTL``
 but you can customize that in the subscriber constructor::
 
     new CustomTtlSubscriber('My-TTL-Header');
 
 The custom header is removed before sending the response to the client.
 
-.. _symfony-cache debugging:
+.. _symfony-cache x-debugging:
 
 Debugging
 ~~~~~~~~~

doc/testing-your-application.rst

@@ -153,7 +153,7 @@ Enable Assertions
 '''''''''''''''''
 
 For the `assertHit` and `assertMiss` assertions to work, you need to add a
-:ref:`custom Cache header <varnish_debugging>` to responses served
+:ref:`custom X-Cache header <varnish_debugging>` to responses served
 by your Varnish.
 
 NginxTest Trait
@@ -225,11 +225,11 @@ CacheAssertions Trait
 
 Provides cache hit/miss assertions to your tests. To enable the these
 ``assertHit`` and ``assertMiss`` assertions, you need to configure your caching
-server to set an `Cache` header with the cache status:
+server to set an `X-Cache` header with the cache status:
 
 * :ref:`Varnish <varnish_debugging>`
 * :ref:`NGINX <nginx_debugging>`
-* :ref:`Symfony HttpCache <symfony-cache debugging>`
+* :ref:`Symfony HttpCache <symfony-cache x-debugging>`
 
 Then use the assertions as follows::
 

doc/user-context.rst

@@ -44,12 +44,12 @@ Caching on user context works as follows:
 3. The :term:`application` receives the hash request. The application knows the
    client’s user context (roles, permissions, etc.) and generates a hash based
    on that information. The application then returns a response containing that
-   hash in a custom header (``User-Context-Hash``) and with ``Content-Type``
+   hash in a custom header (``X-User-Context-Hash``) and with ``Content-Type``
    ``application/vnd.fos.user-context-hash``.
 4. The caching proxy receives the hash response, copies the hash header to the
    client’s original request for ``/foo.php`` and restarts that request.
 5. If the response to this request should differ per user context, the
-   application specifies so by setting a ``Vary: User-Context-Hash`` header.
+   application specifies so by setting a ``Vary: X-User-Context-Hash`` header.
    The appropriate user role dependent representation of ``/foo.php`` will
    then be returned to the client.
 
@@ -121,7 +121,7 @@ It is up to you to return the user context hash in response to the hash request
     $hash = $hashGenerator->generateHash();
 
     if ('application/vnd.fos.user-context-hash' == strtolower($_SERVER['HTTP_ACCEPT'])) {
-        header(sprintf('User-Context-Hash: %s', $hash));
+        header(sprintf('X-User-Context-Hash: %s', $hash));
         header('Content-Type: application/vnd.fos.user-context-hash');
         exit;
     }
@@ -166,7 +166,7 @@ differently depending on whether the user is logged in or not, using the
 
     // /index.php file
     header('Cache-Control: max-age=3600');
-    header('Vary: User-Context-Hash');
+    header('Vary: X-User-Context-Hash');
 
     $authenticationService = new AuthenticationService();
 

doc/varnish-configuration.rst

@@ -161,7 +161,7 @@ To enable support add the following to ``your_varnish.vcl``:
             call fos_ban_deliver;
         }
 
-This subroutine also sets the ``Url`` and ``Host`` headers on the cache
+This subroutine also sets the ``X-Url`` and ``X-Host`` headers on the cache
 object. These headers are used by the Varnish `ban lurker`_ that crawls the
 content to eventually throw out banned data even when it’s not requested by any
 client. Read more on `handling BAN requests`_ in the Varnish documentation (for
@@ -175,10 +175,10 @@ Tagging
 Feature: :ref:`cache tagging <tags>`
 
 If you have included ``fos_ban.vcl``, tagging will be automatically enabled
-using an ``Cache-Tags`` header.
+using an ``X-Cache-Tags`` header.
 
 If you need to use a different tag for the headers than the default
-``Cache-Tags`` used in ``fos_ban.vcl``, you will have to write your own VCL
+``X-Cache-Tags`` used in ``fos_ban.vcl``, you will have to write your own VCL
 code for tag invalidation and change the tagging header
 :ref:`configured in the cache invalidator <varnish_custom_tags_header>`. Your custom
 VCL will look like this:
@@ -262,6 +262,13 @@ To enable support add the following to ``your_varnish.vcl``:
 Your backend application needs to respond to the ``application/vnd.fos.user-context-hash``
 request with :ref:`a proper user hash <return context hash>`.
 
+.. note::
+
+    We do not use ``X-Original-Url`` here, as the header will be sent to the
+    backend and the header has semantical meaning for some applications, which
+    would lead to problems. For example, the Microsoft IIS rewriting module
+    uses it, and consequently Symfony also looks into it to support IIS.
+
 .. tip::
 
     The provided VCL assumes that you want the context hash to be cached, so we
@@ -345,9 +352,9 @@ The custom header is removed before sending the response to the client.
 Debugging
 ~~~~~~~~~
 
-Configure your Varnish to set a custom header (``Cache``) that shows whether a
+Configure your Varnish to set a custom header (``X-Cache``) that shows whether a
 cache hit or miss occurred. This header will only be set if your application
-sends an ``Cache-Debug`` header:
+sends an ``X-Cache-Debug`` header:
 
 Subroutines are provided in ``fos_debug.vcl``.