22022 2013-05-13 18:07:19 +0000 RegisterProtocolHandler needs to accept http POST request, if possible 2016-04-25 22:18:43 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified All All RESOLVED WONTFIX http://www.plam.cantech.bg P1 enhancement Rec 1 follybeachris dave.null follybeachris mike plam public-html-admin public-html-wg-issue-tracking shadow2531 travil public-html-bugzilla oldest_to_newest 87613 0 follybeachris 2013-05-13 18:07:19 +0000 I recently experienced the benefit that HTML5 RegisterProtocolHandler seems to afford users by making use of the "ExportTabs" utility offered to browser-users employing Chrome as their web-tool of choice - and while elated- was equally taken back by the potential drawback that is HTML5/RegisterProtocolHandler/GMail/mailto's inability to parse/handle my POST request to construct an email. I would like to see future spec(s) embrace or enhance this feature-request so as to avoid a cap on the message-body length as is currently being posed by mailto: transforming requests via (I presume) HTTP GET query transformation. IOW, if the ExportTabs browser-extension works in conjunction with the RegisterProtocolHandler() implementation via taking the browser-user's open tabs and converting them (to include various html attributes) to a "mailto:user?body=<http GET request>",then a "mailto:user?body=<POST request>" capability would resolve my concern. I have not contacted the developer as to how their extension works, nor have I TBH conducted suitable research, but to those concerned, your great and attention to this work is indeed very appreciated!! Thank you for your commitment to open web'ed-ness. 87931 1 follybeachris 2013-05-20 17:52:55 +0000 I have reached the developer of the ExportTabs extension in hopes of determining why and/or how Google("Chrome") responds to mailto: when the registeredProtocolHandler for such a request is 'handled' by gmail. According to a post here (http://ow.ly/ldhhs), browser-vendors are apparently free to design paramenter-agnostic handlers such as is the case for handling mailto: requests,anyway.. Without having a more finely detailed specification/contract (perhaps awaiting browser-vendor agreement/discussion on the matter) for how to implement an enhanced mailto: protocol, it seems unlikely that the goal of using HTTP POST as an HTTP request method could be achieved. In other words, I am not aware of any enhanced-contract that binds mailto: protocols to be able to accept parameters or obliges browser-vendors to enable such a request, at this time. 87932 2 follybeachris 2013-05-20 18:06:08 +0000 Mozilla also explains in a way that rules out the possibility, succinctly, here: http://ow.ly/ldknJ 121075 3 mike 2015-06-16 11:33:15 +0000 Raising priority and noting as requiring a minor "feature tweak" to an existing feature. 126131 4 travil 2016-04-25 22:18:43 +0000 HTML5.1 Bugzilla Bug Triage: Incubation needed While it is a small tweak (e.g., to allow parameterized data to be passed (or accepted) by protocol handlers, including whether to use GET or POST, I can't help but think that some other mechanism may solve this use case better. My opinions aside, we'd want to incubate additional changes to these APIs [that are already not universally shipped in browsers (see https://github.com/w3c/html/issues/233). This bug constitutes a request for a new feature of HTML. The current guidelines [1], rather than track such requests as bugs or issues, please create a proposal outlining the desired behavior, or at least a sketch of what is wanted (much of which is probably contained in this bug), and start the discussion/proposal in the WICG [2]. As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process [3]. [1] https://github.com/w3c/html#contributing-to-this-repository [2] https://www.w3.org/community/wicg/ [3] https://wicg.github.io/admin/intent-to-migrate.html