New in Symfony 3.2: HttpFoundation improvements
July 15, 2016
•
Published by
Javier Eguiluz
Warning: This post is about an unsupported Symfony version. Some of this information may be out of date. Read the most recent Symfony Docs.
Added support for SameSite cookie attribute
Contributed by
Ian Carroll
in #19104.
A new cookie attribute called same-site allows applications to disable
third-party usage for any cookie. This helps protect users against CSRF attacks,
because without the cookies, attackers can't see you logged in to the websites
under attack.
In Symfony 3.2, the Cookie class constructor added a ninth argument called
$sameSite that can take any of the values defined in the Cookie::SAMESITE_LAX
and Cookie::SAMESITE_STRICT constants:
1 2 3
use Symfony\Component\HttpFoundation\Cookie;
$cookie = new Cookie(..., Cookie::SAMESITE_LAX);The strict mode prevents any cross-site usage for the cookie. In the lax mode, some top-level GET requests are allowed, such as clicking on a link to another website or sending a form with GET method.
Improved the the response cache headers
Contributed by
Fabien Potencier
in #18220
and #19143.
Previously, if you performed a 301 permanent redirect and didn't set a cache
header, the no-cache header was added by Symfony. In Symfony 3.2 this
behavior has changed and now 301 redirects don't add the no-cache header
automatically, but they maintain it if you set it explicitly.
Symfony 3.2 also fixes another inconsistency related to cache headers. When the
no-cache header is present, Symfony now also adds the private directive,
so the response contains no-cache, private instead of just no-cache.
Added isMethodIdempotent() utility
Contributed by
Kévin Dunglas
in #19322.
HTTP safe methods are those that just retrieve resources but don't modify,
delete or create them (only GET and HEAD methods are considered safe).
The Request class includes a isMethodSafe() method to check whether the
given HTTP method is considered safe or not.
HTTP idempotent methods are those that can be used in a sequence of several
requests and get the same result without any other side-effect. For example
PUT is idempotent because after two identical requests the resource has
still the same state (it's always replaced) but POST is not idempotent
because after two identical requests you will end up with two resources that
have the same content.
In Symfony 3.2 we added a new method called isMethodIdempotent() to check
whether the given HTTP method is idempotent or not.
Help the Symfony project!
As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.
And contrary, POST is not idempotent, because if you do two identical request, you will end up with two resources that have the same content. This one creates a resource, and doesn't update it.
Personally, I won't use this "isMethodIdempotent()" method, if it's not spec-ed correctly :/
Thanks for proposing fixes and improvements to the original post content. I've updated it with your comments.
The thing diverging from the RFC is that PURGE (which is Varnish-specific but was already supported by HttpFoundation) is also considered idempotent (because it is).
A nice summary table is available on Wikipedia: https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Summary_table
I don't know if there was a problem in the first version of this blog post, but the current text is right: PUT is idempotent and POST isn't; according to the RFC.
I know that the Cookie is supposed to be an immutable value object, but could there be a better software design instead of this monumentally huge constructor with now 9 arguments?