Can we just remove thatin_array check? As far as I can see it's not influencing anything internally...
It could be a question of security but it should be solved not by forms but by server configuration.

What if if we move the check fromsetMethod() to$optionsResolver->setAllowedValues('method', [])?

This will give developers a possibility to write an extension for theFormType with$resolver->addAllowedValues('method', ['RESET']) and everyone will be happy :)

@alekitto , why don't you like my solution? Forms have a clear extension mechanism - that isOptionsResolver. Let's use it here!

@vudaltsov in fact i’ve used it in my last revision. I moved the allowedMethods const in FormType and used it to set the ‘method’ option allowed values

@alekitto , I am so sorry, I missed that! Thank you :)

My doubt at this point:setMethod() will accept any custom value butmethod option only the allowed by default, why not open this option too? (i.e. without allowed values) Otherwise, these paths are inconsistent (according to previous behavior).

@yceruto My first proposal on the issue was to remove the check entirely. You can find the reason for maintaining these checks inthis comment

@alekitto Yes, I agree, but this proposal opensetMethod() without restriction...and if we can do this now:

$this->createFormBuilder()->setMethod('RESET');

why can't I do this too (without add a type extension):

$this->createFormBuilder(null, ['method' =>'RESET']);

?

Note that the first alternative doesn't comply with theref comment.

@yceruto You've got a point. I'm still thinking that the best option is to remove the checks and suggest toalways useRequest::METHOD_* constants to avoid misspelling. 

@alekitto I bet on that too 👍

So you suggest one check insetMethod() doingin_array($upperCasedMethod, [Request::METHOD_HEAD...])?

@vudaltsov I understood:remove the checks at all and documenting:**suggest** to always use Request::METHOD_* constants to avoid misspelling..

Is there any restriction to use a custom request method in HTTP world? if no: IMHO, it is not worth sacrificing this natural possibility in favor of the DX misspelling feature.

Technically the standard IIRC does not make any restriction on which HTTP methods you can use. There are some defined in the RFCs for which you are able to infer some semantics but that doesn't stop you from using your own methods. So maybe just removing the check here is the way to go.

@xabbuh Correct. The RFC 7231 defines some method names (GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE) and others have been registered in different RFCs, but does not restrict method names at all.
In fact, it simply definesmethod = token and then lists some standardized methods.

@alekitto Can you also add an entry to the component's changelog file?

@xabbuh Ok, done 👍

The build failure is not related, but requires a fix on how we run tests on Travis CI (#28788 or something like that).

Thank you@alekitto.