Bug : "action" has some remaining trace even after removing it from the form

  • Site : camping-arolla-2018.netlify.app

Context

  • I have a form contact working fine for some years.
  • This form is on every page’s footer.
  • I decided to add action on the form, so I added action = "/my_calling_page/" from every my_calling_page(who change on evey page).

The problem

  • It failed, and on the forum I discover that because this action is a POST i can’t use the same page (called by GET normally). Fine.

  • I decided to remove this action = "/my_calling_page/" snipplet to revert to the original form.

  • And it was not working as expected. I still got URI errors and 404, even if the message was correctly sent.

Bug explanation & workaround

  • Long StoryShort, after LOT of debug, i decided to use a new form contact2 in my form. No other change => And the form was working again fine.
  • I changed back to contact => same problem again.

So i suspect that “somewhere” there is a small trace of my previous use of “action”. it is the only explanation after 3 hours of full debug…

Conclusion

  • With the exact same code, my new form contact2 works fine, and original contact has those troubles.

I’m available to help the Netlify team debug this if it can help.

[EDIT]
I specially created a branch on Netlify who demonstrate this strange behaviour, so Netlify staff can look inside what’s causing this.

Only difference is this branch has original form name contact (the one who had briefly an action parameter.

Message is sent, but we got a 404.

diff --git a/layouts/partials/form_contact.html b/layouts/partials/form_contact.html

index 86837d9..59c2719 100644
--- a/layouts/partials/form_contact.html
+++ b/layouts/partials/form_contact.html
@@ -1,5 +1,5 @@
-<form id="contact-form" name="contact2" method="POST" data-netlify="true" data-netlify-recaptcha="true" netlify-honeypot="surprise">
+<form id="contact-form" name="contact" method="POST" data-netlify="true" data-netlify-recaptcha="true" netlify-honeypot="surprise">
-- 

And I also suspect this is may be related to the fact that I had 2 forms on the same page (worked fine before) and I tried to have recaptcha on both.

And this guy encountered the same problem : 26d

Hi @divinerites,

First, regarding the recaptchas, you won’t be able to using multiple recaptchas on the same page. That’s a known issue. Regarding the ‘action’ attribute, this attribute is not something you can dynamically change. This is set at build time so that is the reason your initial problem occurred.

That said, do you have multiple instances of the ‘contact’ form? Did you change all the instances of that form named ‘contact’ or just one instance of it? Our buildbot will look for all html forms and if it finds multiple forms with the same name, it only retains the for that was last parsed.

Let me know if that helps point you in the right direction.

1 - No you didn’t get the problem : I have NO MORE action in the form, but it STILL BEHAVE as if action is still there. This is “attached” to the form name used.

2 -But more important is that the problem, is still present without workaround on one of my other site ( georgieff-osteo).

I get Bad Request, malformed URI: https://www.georgieff-osteo.fr/informations/ even if I have no action in the form

This site has just one form. And it shows the bug, even if i already removed the action part.
I tried changing form name for contact2, contact3, contact4 but still buggy.

This is important because I have NO workaround for this site.

3 - For the other sites, just renaming the form name was enough as a workaround.

4 - And it is a simple form use by hugo, no javascript or whaterver. Just plain HTML.

It is obvious this a bug related to the fact that “some time before” I had an action on the form.

<div class="contact-form">
   <form id="contact-form" name="contactme" method="POST" data-netlify="true" data-netlify-recaptcha="true" netlify-honeypot="surprise">
       <div class="form-group wow fadeInDown" data-wow-duration="500ms" data-wow-delay=".4s">
           <input type="text" placeholder="{{ i18n "formname" }}" class="form-control" name="name" id="name">
       </div>
       <div class="form-group wow fadeInDown" data-wow-duration="500ms" data-wow-delay=".5s">
           <input type="email" placeholder="{{ i18n "formemail" }}" class="form-control" name="email" id="email">
       </div>
       <div class="form-group wow fadeInDown" data-wow-duration="500ms" data-wow-delay=".6s">
           <input type="text" placeholder="{{ i18n "formtelephone" }}" class="form-control" name="telephone" id="telephone">
       </div>
       <div class="form-group wow fadeInDown" data-wow-duration="500ms" data-wow-delay=".7s">
           <textarea rows="6" placeholder="{{ i18n "formmessage" }}" class="form-control" name="message" id="message"></textarea>
       </div>
       <p class="hidden">
           <label>{{ i18n "human"}}<input name="surprise" /></label>
       </p>
       <input type="hidden" id="type-www" name="type-www" value="Contact" />
       <input type="hidden" id="source-www" name="source-www" value="{{ site.BaseURL }}" />
       <input type="hidden" id="page-www" name="page-www" value="{{ $.RelPermalink }}" />
       <input type="hidden" id="language-www" name="language-www" value="{{ site.Language.LanguageName }}" />

       <div data-netlify-recaptcha="true"></div>

       <div id="submit" class="wow fadeInDown" data-wow-duration="500ms" data-wow-delay=".9s">
           <button type="submit" id="contact-submit" class="btn btn-default btn-send hvr-bounce-to-right animated fadeInUp" value="Send Message">{{ i18n "formsendmessage" }}</button>
       </div>
   </form>
</div>

OK. It’s a nasty bug.

My recaptcha was not showing either.
So I discovered that it was because the site header “Content-Security-Policy” was not set for gstatic.com.
So the recaptcha was not showing because the recaptcha script was blocked because of this Content-Security-Policy.

This is not really normal as a behaviour for the form.

PS : the original bug described here is still present (and i have no Content-Security-Policy for those sites).

Thnaks for helping.

Let me think out loud:

  • netlify process the form and see that a recaptcha is requested.
  • _headers are process by netlify => they can analyse the Content-Security-Policy if it is here.
  • they can see that gstatic.com will be block.
  • 1 + 1 = 2 : netlify can see that :slight_smile:

1 - the recaptcha will not be processed
2 - the form will fail with a Bad Request, malformed URI: https://www.georgieff-osteo.fr/informations/even if the recaptcha was correctly responded.

In case it helps for confirming/or not this problem, this is the HTTP chalenge when the form is sent

Request URL: https://www.georgieff-osteo.fr/informations/
Request Method: POST
Status Code: 400 
Remote Address: 167.99.137.12:443
Referrer Policy: no-referrer
age: 0
cache-control: private, max-age=0
content-length: 73
content-security-policy: script-src 'self' 'unsafe-inline' https://www.google.com https://www.google-analytics.com https://cdn.jsdelivr.net https://*.cloudfront.net https://fonts.googleapis.com https://fonts.gstatic.com https://www.gstatic.com
content-type: text/plain; charset=utf-8
date: Fri, 10 Jul 2020 19:38:52 GMT
referrer-policy: no-referrer
server: Netlify
status: 400
x-content-type-options: nosniff
x-frame-options: DENY
x-nf-request-id: 7e909e83-67e9-4704-a205-7d21c219e7f7-281476
x-xss-protection: 1; mode=block
:authority: www.georgieff-osteo.fr
:method: POST
:path: /informations/
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
accept-encoding: gzip, deflate, br
accept-language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
cache-control: no-cache
content-length: 283
content-type: application/x-www-form-urlencoded
cookie: cookieconsent_status=dismiss; displayCookieConsent=y
dnt: 1
origin: null
pragma: no-cache
sec-fetch-dest: document
sec-fetch-mode: navigate
sec-fetch-site: same-origin
sec-fetch-user: ?1
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Mobile Safari/537.36
form-name: contactme
name: Didier "divinerites" GEORGIEFF
email: divinerites@gmail.com
telephone: 0673692914
message: test 1023
surprise: 
type-www: Contact
source-www: https://www.georgieff-osteo.fr/
page-www: /informations/
language-www: Français

`
``

Hello,

I’m not sure you are talking about the same issue anymore. If it’s a different issue, would you be ok in creating a new post for that issue just so we don’t lose site of the original issue?

That said, I believe the issue with the action getting ‘stuck’ even when it is no longer in your code is a bug. A workaround would be to change your form’s name attribute. This will trigger our system to create a completely new form definition for the form without the action attribute. I’ll get an issue filed on our end regarding the stuck ‘action’ attribute.

With regards to your other issue, we won’t hold your hands as far as setting up custom headers using a _headers file. There is no validation across features so you will need to know the consequences of the custom headers that you add to your site. That said, I remember that you included the domain that the recaptcha uses (gstatic.com) to your CSP headers to avoid the issue you mentioned. If that doesn’t work for you, please do start a new post for the issue to avoid confusion.

Thanks!

Yes, a bug for sure. Thanks for taking time to confirm this.

Yes, thanks. This the workaround I used quickly. Works fine.

Yes, fair enough.
And updating the CSP seemed to be the solution.

Thanks for all.

1 Like

Got the issue filed! We update when and if the issue gets fixed. Thanks for your patience.

So, it looks like a fix has been deployed to make sure that the ‘action’ attribute gets updated. Let me know if you still run into this issue. Thanks for your patience!

[EDIT] sorry I mixed up issues :slight_smile:
Thanks I’ll test it ASAP when I can on a test site. Again thanks.