Closed Bug 1437360 Opened 2 years ago Closed 1 year ago
XHR PUT of JSON comes with a XML parsing error (not on Safari or Chrome)
Bug 1437360 - do not attempt to parse XHRs as XML if content-length=0, to prevent logging "no root element found" errors; r?smaug
47 bytes, text/x-phabricator-request
|Details | Review|
Hello, I've tried to reproduce your issue by creating a test case: https://devtools-html-put-error.glitch.me/ (edit URL is https://glitch.com/edit/#!/devtools-html-put-error?path=server.js:31:18), but I can't see the error you experienced. Am I missing something in my code to reproduce the error ?
Thanks for the effort. As you say this is not showing the error in my Firefox (so my particular FF and other WebExtensions/Plugins are not the variable). I have other variables involved - like a Python dev-local webserver. And Vue.js although the snippet of code I shipped was vanilla XHR rather than more elegant 'Vue-router' logic. I'll use your app as a starting point to in order to introduce things one by one towards a reproduction (and root cause via process of elimination). Or not of course. I may end up filing an issue elsewhere and updating this one to say so. I'd not seen glitch before - neat.
Yeah it is the kitchen-sink PUT-ized Python SimpleHttpServer that is the root cause. It handles and saves the payload just fine, but the response isn't enough - probably content length, or type or something else. I'll just switch to Node as a PUT handler for my "local development server". Should I close this? Or is the problem statement different now: "In PUT situations, Firefox reports an XML error when it is actually incomplete response from the server" ? Thanks again for your repro effort, Nicolas.
I think we should keep the issue and rename it to accurately represent what it is. Could you post the headers from the response so we know what's wrong in the response and can reproduce it ?
Firefox listed nothing at all for the response from the Python process. I'm going to have to crank up Charles (logging proxy) or similar to see what actually came back. Stand by ..
The sample PUT enhanced SimpleHttpServer needs to look like this to work: ``` import SimpleHTTPServer import BaseHTTPServer class SputHTTPRequestHandler(SimpleHTTPServer.SimpleHTTPRequestHandler): def do_PUT(self): length = int(self.headers["Content-Length"]) path = self.translate_path(self.path) if ".json" not in path: raise Exception("not allowed") with open(path, "wb") as dst: dst.write(self.rfile.read(length)) self.send_response(200) self.send_header("Content-Type", "text/plain; charset=utf-8") if __name__ == '__main__': SimpleHTTPServer.test(HandlerClass=SputHTTPRequestHandler) ``` The XML parsing error goes away. There was a missing content type (regardless of the absence of content) If the content type line is commented out the XML error appears in Firefox (regardless of the absence of content). If the content type and '200' line are reordered then there is a different error - neither the 'PUT worked' or 'PUT failed' callback is invoked. With just the two in the correct order, FF works fine. It doesn't wibble about a missing content length, or missing content. At least not in the console. SeaMonkey has this issue too, so the issue is pre-quantum which probably doesn't surprise any of the veterans of the larger Moz codebase.
I've encountered this as well in a webapp I work on. If Content-Type is missing Firefox attempts to parse the response as XML which results in the console error. The workaround for webapps is to send a Content-Type of "text/plain" but it'd be nice if Firefox did not attempt to parse the content like Safari and Chrome do.
Mostly just a "me too" post, but I thought it may be worth adding that this occurs with AWS S3 direct uploads. Specifically S3 will respond to a PUT file upload with 200 status code and "Content-Length: 0" without any Content-Type being included.
Component: Console → Networking
Product: DevTools → Core
Assignee: nobody → twisniewski
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/6b9aee567032 do not attempt to parse XHRs as XML if content-length=0, to prevent logging "no root element found" errors; r=smaug
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Component: Networking → DOM: Networking
You need to log in before you can comment on or make changes to this bug.