You can clone with
No one assigned
I'm the admin of userstyles.org. I offer user script versions of my user styles for Greasemonkey users. I also have an option that lets authors give users options for the styles, see for example http://userstyles.org/styles/70561/glassfox-choose-your-personal-newtab
I want to add a new feature that would let users upload images for use in the styles. The way this works internally is that there would be a file upload control on my site, and when they choose install, it sends the uploaded file to my server, which then responds with the user style/script with their chosen image at the appropriate spot in a data: URL format.
Due to URL length limits, this request cannot be a GET. When I test serving up user scripts with a POST, I see that Greasemonkey appears to be intercepting the request and issuing a GET instead. The GET is missing the request body, so the user script is not functional. When I disable Greaseminkey, the request appears to function as I expect.
So my request here would be that if Greasemonkey sees that a user script request is a POST, it should keep it as a POST and retain the request body.
Your request makes sense. I don't know right now how practical/easy it would be to intercept and replay the POST body. I'll look into it but I'm not sure when/if it will work.
What would probably be an easy work around is a relatively standard POST handling paradigm: POST to some other handler, upon success, 30x redirect somewhere else to display success. In this case, to a handler that will offer a user script referencing the just-uploaded image.
I set up my server to respond to a POST to a .user.js with a redirect to a GET to the same URL, storing the parameters in the server-side session. Greasemonkey intercepts the POST and issues the GET directly, and the parameters get lost.
I then set it up to POST to a non-.user.js URL which then redirects to a .user.js GET. In this case, I get the correct file contents displayed, but Greasemonkey does not trigger its install dialog.
Apparently nsIContentPolicy doesn't handle HTTP redirects (so the proposed workaround, as mentioned, won't work), though nsIChannelEventSink (via category net-channel-event-sinks) has some capability to do that (but that would need to be added). A (confirmed) workaround to the workaround would be a <meta http-equiv="refresh" ...> rather than an HTTP Location header redirect. But then the POST handler needs to display something to the user; its response will still be visible.
<meta http-equiv="refresh" ...>