Problem/Motivation
The reverse proxy configuration and documentation in default.settings.php has some minor issues:
- copy/paste errors: most of the comments refer to "client protocol" instead of the setting's actual meaning
- confusing/wrong default values: while most of the commented out $settings code lines have the actual default value, the doc comment has not (e.g. doc: "X-Forwarded-Proto", code/default setting: "X_FORWARDED_PROTO") - verified in Drupal\Core\StackMiddleware\ReverseProxyMiddleware
- unclear difference between "reverse_proxy_header" and "reverse_proxy_forwarded_header" (rfc 7239)
Proposed resolution
Is only a minor issue, but it still takes some time to figure out what's wrong, so it should be fixed by updating the documentation.
Remaining tasks
Needs review / merge.
Comment | File | Size | Author |
---|---|---|---|
#17 | interdiff-2673572-11-17.txt | 1.49 KB | chipway |
#17 | improve-reverse-proxy-documentation-2673572-17.patch | 1.94 KB | chipway |
#11 | improve-reverse-proxy-documentation-2673572-11.patch | 1.61 KB | Saphyel |
#8 | improve-reverse-proxy-documentation-2673572-8.patch | 1.62 KB | patrick_durold |
Comments
Comment #2
patrick_duroldFixed errors and unclear wordings. Added link to rfc7239.
Patch is against current 8.0.x branch.
Comment #3
patrick_duroldComment #4
jhodgdonThanks for the issue and patch! The patch needs some work before we can commit it though:
I don't understand the code (or commented-out code) change here. The docs say that you should only set this value if you are not using X_FORWARDED_FOR, so the line that was previously in this file gave an example of something you might set it to. I don't think we should change it, since setting it to X_FORWARDED_FOR is not something anyone would ever set it to, right???
This line is now over 80 characters, so you need to rewrap it.
I also don't understand why you felt it was necessary to add "original" to all of these lines. I think it should probably just be taken out, but if it *is* necessary, you need to rewrap the docs so they don't go over 80 character lines.
remove "original" or rewrap here too.
here too
This is over 80 characters too.
This is not how @link works. See
https://www.drupal.org/node/1354#link
for more information. Probably rather than @link you either want @see or just the URL in a sentence anyway?
Comment #5
patrick_duroldWell, understanding is always subjective, so I added what I thought would be needed for me personally to immediately understand it. As said, that's a personal view.
1. My thinking was that if the other four reverse proxy settings use the default value as example, this one should too. It's more consisting and a bit less confusing, at least for me. Changing the one example was the smallest change that would achieve that (instead of conjuring up some random examples for the other four).
Also, it's not uncommon for config files to have the default value commented out, so it felt okay for me.
Kept this in the patch (for now). If you really think it shouldn't be changed, then please consider using non-default examples for the other four settings.
2.-5. Sometimes I'm a bit overly verbose. I removed the "original".
6. I mixed that up with phpDoc. Changed that to "@see".
Comment #6
patrick_duroldComment #7
jhodgdonFair enough! So the latest patch looks good, except one small nitpick:
Thanks -- @see works better here. But you need to leave a blank line before an @see line.
Comment #8
patrick_duroldAdded blank line before @see.
Comment #9
jhodgdonAlmost there!
There is an extra space at the end of this line.
You should be able to set your code editor or IDE to either remove or highlight end-of-line spaces.
Comment #10
Saphyel CreditAttribution: Saphyel as a volunteer commentedComment #11
Saphyel CreditAttribution: Saphyel as a volunteer commentedFixed #9, good work guys!
Comment #12
jhodgdonLooks good now, thanks everyone!
Comment #13
catchThese are the actual header names, which is what's referred to in the docs, I don't think we should just switch to referring to the constants here.
Comment #14
patrick_duroldCould you please elaborate? The values that look like constants are the actual header names accepted by Drupal. What do you propose instead?
Comment #17
chipway CreditAttribution: chipway at Chipway commentedThanks all,
Here is a new patch suggestion.
Comment #19
Munavijayalakshmi CreditAttribution: Munavijayalakshmi at Valuebound commentedComment #20
catchI still think the comments should match the actual HTTP headers rather than the constants here since that's what they're referring to.
Comment #21
chipway CreditAttribution: chipway at Chipway commentedThanks Catch,
I try to understand. As we speak about custom proxy headers, we can't use the ones from https://tools.ietf.org/html/rfc7239.
Do you mean something like the following?
+# $settings['reverse_proxy_header'] = 'Your-Customized-X-Forwarded-For';
or
+# $settings['reverse_proxy_header'] = 'X-Forwarded-For-Customized';
Comment #22
Munavijayalakshmi CreditAttribution: Munavijayalakshmi at Valuebound commentedComment #25
tunic@Catch can you clarify what is the problem? I'm not sure what fix is needed. See #21.
Not a functional bug, but it's not good for Drupal to have such errors in the official example configuration file.
Comment #27
O'Briat CreditAttribution: O'Briat as a volunteer and at Capgemini for SNCF, E.voyageurs Technologies commentedThere's another issue about this wording: https://www.drupal.org/project/drupal/issues/3017957
- For X_FORWARDED_HOST, I suggest to use "the original host requested by the client" instead of "the client host"
- For X_FORWARDED_PORT, I suggest to use "the original port requested by the client" instead of "the client port"
Comment #33
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer and at QED42 for Drupal India Association commentedThis issue is probably outdated now because of #3030501
As part of #3030501:
Following settings were deprecated and their documentation was removed from
default.settings.php
reverse_proxy_header
reverse_proxy_proto_header
reverse_proxy_host_header
reverse_proxy_port_heade
reverse_proxy_forwarded_header
Which fixes the all the documentation issues mentioned here.
Comment #34
dipakmdhrm CreditAttribution: dipakmdhrm as a volunteer and at QED42 for Drupal India Association commentedClosing because of the above comment. Feel free to reopen if you disagree.