Added support for SameSite cookie attribute
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
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
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.
The first pull request is actually located at https://github.com/symfony/symfony/pull/19104.
I think you got what PUT and POST are for mixed up there :) POST is usually for creating new, PUT is for editing existing. PUT is idempotent though, that much is right!
Shouldn't it say that PUT is idempotent because after two identical requests the resource has still the same state, because it will always be replaced? PUT doesn't create a resource, it modifies a resource. 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.
+1 on Stephan Wentz' comment
According to HTTP specs, POST creates a new resource, PUT updates a whole resource and PATCH updates part of a resource...
RFC about PUT and POST: https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
Personally, I won't use this "isMethodIdempotent()" method, if it's not spec-ed correctly :/
@Philipp fixed the PR number. Thanks!
Thanks for proposing fixes and improvements to the original post content. I've updated it with your comments.
@Alex Which part of the method do you consider to not be according to the spec?
@Alex: this new method is based on the RFC and is 100% compliant with it.
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?