Search code examples
vb.netasp.net-mvc-4httpasp.net-web-apiemail-client

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


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...)

Solution

  • 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).