New in Symfony 3.2: HttpFoundation improvements

Warning: This post is about an unsupported Symfony version. Some of this information may be out of date. Read the most recent Symfony Docs.

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.


The first pull request is actually located at
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:

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:

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.
> In Symfony 3.2, the Cookie class constructor added a ninth argument called [...]

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?

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.