[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #9481 [HTTPS Everywhere: Chrome]: Header value being duplicated
#9481: Header value being duplicated
--------------------------------------+-------------------------------------
Reporter: boushley | Owner: pde
Type: defect | Status: new
Priority: major | Milestone:
Component: HTTPS Everywhere: Chrome | Version:
Keywords: | Parent:
Points: | Actualpoints:
--------------------------------------+-------------------------------------
When using HTTPS Everywhere for Chrome I've tracked down some errors with
headers not being passed properly. Some of the headers returned from the
service actual end up being doubled when HTTPS Everywhere is enabled.
I tracked this down in an application I'm writing that makes CORS HTTP
Requests to the Dropbox API. I was seeing "SyntaxError: Unexpected token ,
" errors similar to this issue:
https://trac.torproject.org/projects/tor/ticket/5952 but not in relation
to Bootcamp. As I dug into the issue it became clear that a header that
was supposed to be JSON was malformed.
After inspecting the header through Chrome's Network panel, and then
through another proxy (to ensure it wasn't the server sending a double
header) it became clear that the server was sending a valid response, but
javascript inside of Chrome was seeing a broken response. The headers for
the actual request are similar to the following:
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 10 Aug 2013 11:26:57 GMT
Content-Type: text/plain; charset=ascii
Content-Length: 203
Connection: keep-alive
accept-ranges: bytes
x-dropbox-metadata: {"revision": 7, "rev": "7130446f9", "thumb_exists":
false, "bytes": 203, "modified": "Fri, 09 Aug 2013 11:55:51 +0000",
"client_mtime": "Fri, 09 Aug 2013 11:54:52 +0000", "path": "/some_file",
"is_dir": false, "icon": "page_white", "root": "app_folder", "mime_type":
"application/octet-stream", "size": "203 bytes"}
x-server-response-time: 200
etag: 7n
x-dropbox-request-id: 5fcfa0e9c0b1f00039d8901aaaad6738
pragma: public
cache-control: max-age=0
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Accept-Ranges, Content-Range, X-Dropbox-
Metadata, X-Dropbox-Request-Id, X-JSON, X-Server-Response-Time
X-RequestId: f89f279185cc3bcf4c5deeeeaaaeaaaa
The header that I was having problems with is the x-dropbox-metadata
header. The value returned from the server was valid, but when javascript
called xhr.getResponseHeader('x-dropbox-metadata') or
xhr.getAllResponseHeaders() the value for 'x-dropbox-metadata' would be
the correct value twice comma separated. So in this case we would see:
{"revision": 7, "rev": "7130446f9", "thumb_exists": false, "bytes": 203,
"modified": "Fri, 09 Aug 2013 11:55:51 +0000", "client_mtime": "Fri, 09
Aug 2013 11:54:52 +0000", "path": "/some_file", "is_dir": false, "icon":
"page_white", "root": "app_folder", "mime_type": "application/octet-
stream", "size": "203 bytes"}, {"revision": 7, "rev": "7130446f9",
"thumb_exists": false, "bytes": 203, "modified": "Fri, 09 Aug 2013
11:55:51 +0000", "client_mtime": "Fri, 09 Aug 2013 11:54:52 +0000",
"path": "/some_file", "is_dir": false, "icon": "page_white", "root":
"app_folder", "mime_type": "application/octet-stream", "size": "203
bytes"}
This caused a syntax error when parsing this value as JSON which is the
symptom I mentioned at the start.
This problem reproduces every time for me, until I disable https
everywhere. I tried disabling each of my plugins one at a time, and found
that HTTPS Everywhere reliably causes this problem.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9481>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs