-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JApplicationWeb::setHeader behavior #9819
Labels
Comments
I already attached a demonstration plugin, and proposed a solution to JApplicationWeb::setHeader - how is it 'No Code Attached Yet'? |
Because there is no pull request |
I see...I need to learn how to do that |
That wasn't nearly as difficult as I thought it would be Thanks Brian |
Closing as we have a PR for testing #9836 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The structure of the setHeader method is a little confusing considering the names of the parameters. The third parameter ($replace) would indicate that if an existing value is present for the $name, that the header would not be set unless $replace is true - but this is not the case. $replace = true merely deletes an existing value. If $replace = false or is not set - an identical (duplicate) value may be added to the array - giving 2 headers with the same name, obviously only the last added header would be used. So, the way the method operates - $replace does nothing, because a duplicate entry in the headers array replaces any previous entry when the headers are set.
Steps to reproduce the issue
$app = JFactory::getApplication();
$app->allowCache(true);
$app->setHeader('Expires',gmdate('D, d M Y H:i:s', time() + 1000) . ' GMT',true);
Example plugin attached:
plg_setheader.zip
Expected result
Expires header 1000 seconds in the future
Actual result
Expires header 900 seconds in the future
System information (as much as possible)
J3.5.1
Additional comments
This is the result because 900 seconds is set in JApplicationWeb on line 451. I set the header, and another is added by JApplicationWeb in the 'respond' method. setHeader appends a duplicate to the response header array when $replace is false. So when the Expires header is set in the response, it's set over-and-over until the last 'Expires' header is retrieved from the array - and that last one is the one that's sent.
If setHeader behaved as one might expect - JApplicationWeb wouldn't be able to add another Expires header value.
I've attached an modified JApplicationWeb::setHeader which behaves as expected - an item can only be replaced if $replace is true - and an item is never duplicated.
web.php.zip
The text was updated successfully, but these errors were encountered: