html form sent from an iPhone

[ginerjm]

Here's the scenario. I have a php script that is triggered by an email piped to it on my server. The script does its thing and then sends a message and a form with a submit button back to my email address. The form specifies a GET request and the form has an action that includes a couple of arguments attached to it.

 

Example:

<form method='GET' action='http://myscriptname.php?arg1=xxx&arg2=yyy'>
<input type='submit' name='btn' value='View Grid'>
</form>

Now here's the problem.

 

When this form is received by my email at my laptop, the button, when clicked does exactly what it looks like it should do as above. It triggers a script with the two GET args included in the url. The script sees the values and executes accordingly. Perfect!

 

But - when the email is picked up on my iphone, while it looks exactly the same, when I click it the script does NOT pick up the args in the action's url. What it picks up is the submit button as if the form was doing a POST. Of course the script sends an error message to me and does not do what it is supposed to do.

 

So - why does the iphone treat this html email form as a POST but my other devices (laptop) see it properly as a GET request?

[Psycho]

Have you used var_dump() on $_POST and $_GET to see exactly what is sent?

 

I don't use Apple products, so I can't be sure, but I'm guessing that either the phone OS or the email client on the phone may be filtering the parameters. Most email programs will not show images by default because spammers can attach different parameters (or use slightly different URLs) to the image URL to individually identify which users have opened the emails. Perhaps the behavior you are experiencing is some sort of similar implementation to protect users.

 

Then again, since the method is GET, the intent would be for any form fields to be included in the URL - but you have already included variables in the URL via the action parameter. Perhaps that is causing some confusion in how the form is handled in the email. Why not change the method to POST. There are not fields in the form, so the variables in the action parameter would still be accessed via GET anyway.

Edited June 3, 2016 by Psycho

[ginerjm]

Actually I did just what you said. Changed the method to POST and voila! all is working fine. I did change my script to retrieve my supposed GET args as REQUEST ones.

 

Funny how the two environments differ. One treats the form as a GET always and passes along the uri string. The other respects the form tag's method= but ditches the uri args in favor of the form element.

[Psycho]

Funny how the two environments differ. One treats the form as a GET always and passes along the uri string. The other respects the form tag's method= but ditches the uri args in favor of the form element.

 

Not really. As I stated above, the target for the form already has arguments on the URL and since the method is GET the intent is for the form fields to be appended to the target URL. Of course, you didn't have any form fields, but the scenario does not have strait forward solution.

 

Based on my reading of the official specs for the form method of GET it is ambiguous as to what should exactly happen

 

 

get: With the HTTP "get" method, the form data set is appended to the URI specified by the action attribute (with a question-mark ("?") as separator) and this new URI is sent to the processing agent.

 

If the browser was to render the URL exactly to that definition it would be a malformed URL. Example:

<form action="http://domain.com/somepage.php?foo=1" method="get">
    <input type="text" name="bar" value="2">

If that code was posted and the full URL was compiled per the specs it would end up as

domain.com/somepage.php?foo=1?bar=2

 

So, the application processing the form needs to detect that there is already a question mark in the defined target and make a decision. Either 1) Remove the existing data after the existing question mark and append the form field data or 2) Append the form field data to the full target URL using a plus sign.

Edited June 4, 2016 by Psycho

[requinix]

Based on my reading of the official specs for the form method of GET it is ambiguous as to what should exactly happen

HTML 5's spec is a little better. The fun part is in the "Mutate action URL" behavior (which is what happens with method=get), but it has a flaw where the "parsed action" is undefined. However I think it's clear that the intention is to replace the parsed form action's query with the encoded form data, thus discarding whatever may be there already.

 

So,

1. Switch to POST method? That's a matter for whether GET or POST is more appropriate for the action - the data and technical behavior of form submission are irrelevant. Given that it sounds like a "view"-type of action, GET seems more appropriate to me.

2. Keep GET? If you do then you simply put the arg1 and arg2 in the form as hidden inputs.