0

The title pretty much says it all, but for those wanting a bit more context: in our specific use case, the back-end API must reply to some HTTP GET requests with a redirection to an email address (with the typical purpose of automatically opening the end-user's email client).

For those wondering why we don't simply link to the actual email address directly in the UI, the reason is that the specific email address is unknown at the time the UI is displayed because it varies depending on the specifics of the request. And also, because the front-end must not rely on JavaScript, this must therefore be handled by the back-end.

So, should this redirection be a 303/seeother? I have read this Wikipedia page but am still unsure whether a mailto: URL qualifies as a resource for which "the origin server does not have a representation".

(Is this the correct SE site for this question or would it go better on Stack Overflow?)

Improve this question
4
  • I would just link the mail button to a page that performs the necessary action and then triggers the mailto function to open the mail client. If you need coding support then SO, if it is a webmaster quest en then webmasters would be more fitted imho. This site is to support Businesses Administration within a Business environmental. If you are not sure about which status code you should use, I suggest you to read the (MediaWiki)[en.m.wikipedia.org/wiki/List_of_HTTP_status_codes] since it is always different I would use a temporary redirect Commented Apr 2, 2024 at 5:39
  • I'd argue it's wrong. That also means users can't right click to copy e-mail address and paste into whatever email client they want. Commented Apr 2, 2024 at 6:15
  • @djdomi: This is not a coding question, perhaps a webmaster one, though. I am acting as a system administrator, currently configuring the app's reverse proxy which performs the function described above. I am familiar with HTTP status and would intuitively pick 302/found (temporary), but I want to be thorough and make sure that 303 isn't a better pick for this particular case. As for linking to another page that performs the action, I'm not sure how that could work without JavaScript? Commented Apr 2, 2024 at 13:30
  • @vidarlo: I understand your point, and we are indeed using JavaScript to improve user experience. We're just making sure the app doesn't require JavaScript. This function is part of a use case that is somewhat too complicated to explain here. You may abstract the question from its context if you prefer. Commented Apr 2, 2024 at 13:37

0

Reset to default

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.