Hello, We have been having an issue with our embedded forms submissions not getting logged/saved in Marketo... This only happens if the user that submitted the form has a (can be any name) cookie with a value that has two or more encoded spaces (yes it can have one, but no more!). We have tested on a mkto landing page with no extra scripts and only a single cookie in the browser with the two or more encoded spaces, submit the form, then check for the user activity but nothing will be there. As soon as we clear the cookie or reduce the encoded spaces to one or none then submit the form we see the form activity.
Example Cookie value that will fail
Encoded: my%0Acookie%0Ahas%0Afour%0Aspaces
Decoded: my cookie has four spaces
Example Cookie value that will work
Encoded: mycookie%0Ahasonespace
Decoded: mycookie hasonespace
Curious if anyone else has seen this issue?
Please link to your test page.
Also —
btw can’t reproduce this at all.
Clarifying the issue.... The form submission will appear to work for the end user. But if you look at the marketo database the user activity/submission does not show at all. So the issue is more on the marketo backend and how its parsing the cookies (cause we can only re re-create based on the cookie info I previously mentioned).
Test page used: https://p.highspot.com/Test-Marketo-001.html
When I submit this form with my own info and DO NOT HAVE a cookie with 2 or more encoded spaces:
- the form will work as expected and take me to a TY
- the form submission and activity is logged/visible in the marketo database
When I submit this form with my own info and DO HAVE a cookie with 2 or more encoded spaces:
- the form will work as expected and take me to a TY
- the form submission and activity is NOT logged/visible in the marketo database
OK, you’re on to something here. More than one %0A character does create the behavior you described. Though I need to point out again that %0A is not a URL-encoded “space“ (as in horizontal space) — it’s a line break. A standard space %20 doesn‘t create a problem.
Another thing to mention is cookies and URL-encoding don’t actually have any special relationship, which is not to say you shouldn’t be allowed to store the percent sign followed by two characters in a cookie value, but that’s not a sequence that per specification has any special meaning. It’s just 3 characters that would mean something special in a URL... but a cookie isn’t a URL. Obviously there’s custom code on the server end that’s treating a URL-encoded value as special, trying to decode it, and believing the line break is somehow unnatural/malicious/unexpected. But again, a standards-compliant server wouldn’t even bother decoding the value unless it knew that a cookie set by a certain process was URL-encoded.
I can provide you some code that would work around the problem, but it would only apply to JS-accessible cookies. HttpOnly cookies can’t be seen at all by JS, but they can be seen by the server. Do you know what‘s setting the cookie with %0A?
Thank for clarifying what %0A is, makes sense.
The cookies with %0A are dropped by an app we control and both are http only. We are investigating what it would take for us to modify how we store these cookie values as a work around but not our preferred solution.