[tor-bugs] #9481 [HTTPS Everywhere: Chrome]: Header value being duplicated

[Tor Bug Tracker & Wiki]

#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