How to avoid launching browser when a link within email message is clicked

Question

Currently, part of my application sends out emails to users reminding them of events or tasks. When clicking a MarkComplete link in the email client, an HTTP Get request is made to my ActionHandler.ashx (an HTTPHandler) where the QueryString parameters are inputs allowing for the update of the event/task. New emails are then emitted back to the client signalling completion. This works.

An unwanted side-effect of this HTTP GET to the handler is the launching of the browser (i.e. at this point, the opening of the browser is unneeded and a nuisance).

Premise: As I study up on the ASP.Net Web Api, I am thinking I might be able to refactor the small amount of code in my HTTPHandler into a PUT method in a Web API controller. My understanding is that this controller could respond with void return (HTTP status code 204) after doing the required processing described above.

Question: Can the above approach in a newly written PUT method in a Web API controller return 204 and will this prevent the browser from launching completely? I want the end-user to click the link in his first email and only get the newly constructed email message signaling "completion" (no browser at all here).

EDITs to clarify 22 May 2016:

• I do NOT NEED "user interaction". Ideally, the user clicks and nothing happens to the user than a new "answering email" indicating successful completion of the task.
• Option 2 listed in proposed answer below has already been tried unsuccessfully and some major email programs do not allow this - see: Submit to HttpHandler results in RequestType GET instead of POST
• Please note the HTML email content currently emitted does NOT contain any HTML form tag(s) bracketing the link tags in the message.
• Do I still indeed have NO options? I have read that HTTP PUT can process a querystring (I just don't know exactly how to do so yet...)

Answer 1

Short answer: No.

If you need user interaction, then there is no way to execute an HTTP request from an Email client without opening the browser.

The majority of Email clients (web mails included) do not allows you to execute JavaScript code and thus you have no option on executing something in the background.

This means that you have two options:

1. Create a link inside your Email that will result into a GET request to your web server (this is what you have already done). This, of course, results in the browser opening to that page.
2. Create a HTML form inside your Email, with an hidden field containing your data, that will target a POST enabled endpoint inside your web server. This will also cause the web browser to be opened (and may also show a warning message in some scenarios), but lets you better handle what kind of data to send. BUT it appears that this approach is tightly bounded to the specific client behavior (e.g. Thunderbird turns every form submit into a GET request), so I do not believe it is doable.

Apart from those two options I believe you have no possibilities. The reason behind this is purely related to security: it would be very insecure if you could be able to execute JavaScript code inside an Email message.

The 204 Response

What you can do, is to turn the response of your endpoint into a 204 (like you proposed). Please note that this will also cause your browser to open but it will almost immediately close the tab that responded with a 204 (the exact behavior depends on the Email client and Web browser combination). I think this can easily be done even if you do not change your code base and keep using your ActionHandler.ashx, but if you want, is of course easily done in ASP.NET Web API by just returning void from an ActionMethod.

Regarding the PUT method:

In HTML forms only GET and POST are allowed methods, while any kind of <a href="... ">...</a> tag will always generate a GET request. This means that you will not be able to execute the PUT method inside an email message (no matter in which environment the email is read).

Answer 2

Having an action within an email needs to open a web browser. otherwise it would be a big security concern on the clients side. If this was an option this would open the door to spammers, and hacks to have an email where you click anywhere and automatically download an application (BIG SECURITY CONCERN).

There are other ways to handle this type of application, we use Text messaging as well as PDF forms that can reply to an application request, SharePoint will do this as long as the client is part of your infrastructure. Google is now doing this with with markup for a kind of RSVP and highlight emails but only works on clients that will look at the markup language and google with their apps. Most email clients will ignore markup and scripts in an email.I really do not know of anyone that does not have a cell phone in today's age, even my grandmother at 75 years of age has a cell phone. I would recommend using twilio and SignalR. another way would be to setup a few email accounts that your application will monitor, let say [email protected] and [email protected]. Now when the client accepts it will send response to that email and your application can look at the email address in the header to mark that account, this also gives you records to look back on if there was a problem with the client.

As for the browser opening i do not believe this is a bad thing, This will send them back to your application and force them to see new information, events or tasks you have posted (Marketing).