Request #50009
From:
Account Type:
Paid Account
Dreamwidth:
Support category:
Time posted:
Tue, 15 Apr 2025 17:49:52 GMT (22 weeks ago)
Status:
Open
Summary:
Exporter tool: Generated xml page opens in browser, but not downloadable
Original Request:
Hi. I've tried several times, in two different browsers, to download all my posts from January 2007 (the first step in downloading the next several months' worth). The exporter tool seems to generate the correct XML page and my browser shows it to me fine, but then when I try to save the result to a local file I get a different, small (14kB) XML file, containing (in amongst the usual XML gobbledegook) the following error message:
"As a security precaution, the page you're viewing requires a POST request, not a GET. If you're trying to submit this form legitimately, please contact us."
Q1: How can I download the actual XML I'm seeing in the browser?
Q2: Why is it necessary for the XML to be opened in a browser window first at all? (Especially since this is by no means the only case I've found where telling a browser to save what's displayed gets the wrong result).
The two browsers I've tried are Brave and Opera. I think they're both based on the same Chrome engine... [HAS AN IDEA, FIRES UP LONG-DISUSED COPY OF OF FIREFOX]... Aha! It works as intended in Firefox, but not the two Chrome-based browsers.
OK, I can use that for now as a workaround; but it really would be good to get things working correctly in the other browsers. Is it a bug in Chrome, do we think, or a case of Dreamwidth and/or Firefox not keeping up with revised standards?
Diagnostics: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36
"As a security precaution, the page you're viewing requires a POST request, not a GET. If you're trying to submit this form legitimately, please contact us."
Q1: How can I download the actual XML I'm seeing in the browser?
Q2: Why is it necessary for the XML to be opened in a browser window first at all? (Especially since this is by no means the only case I've found where telling a browser to save what's displayed gets the wrong result).
The two browsers I've tried are Brave and Opera. I think they're both based on the same Chrome engine... [HAS AN IDEA, FIRES UP LONG-DISUSED COPY OF OF FIREFOX]... Aha! It works as intended in Firefox, but not the two Chrome-based browsers.
OK, I can use that for now as a workaround; but it really would be good to get things working correctly in the other browsers. Is it a bug in Chrome, do we think, or a case of Dreamwidth and/or Firefox not keeping up with revised standards?
Diagnostics: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36
Still interested in learning more, if anyone has any clues.
You must log in to answer Support requests.
Go to: previous open request, next open request
Return to the list of open requests.
Back to the Support Area.