Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sometimes text responses are gzipped, despite no Accept-Encoding header #2691

Closed
russellmcc opened this issue Oct 23, 2016 · 5 comments · Fixed by #2723
Closed

Sometimes text responses are gzipped, despite no Accept-Encoding header #2691

russellmcc opened this issue Oct 23, 2016 · 5 comments · Fixed by #2723

Comments

@russellmcc
Copy link
Contributor

russellmcc commented Oct 23, 2016

I'm trying to get the davros WebDAV app working with the Mac OS X Finder. There's an issue in davros that's blocking this (mnutt/davros#74), but it looks like on a branch where that issue is fixed there's a sandstorm problem. Here's the request headers to my local sandstorm:

PROPFIND /remote.php/webdav/ HTTP/1.1
Host: api-a4d7d859e9d223c3449c4deea2c2d200.local.sandstorm.io:6080
Content-Type: text/xml
Depth: 0
Accept: */*
User-Agent: WebDAVFS/3.0.0 (03008000) Darwin/16.0.0 (x86_64)
Authorization: Basic dW50aXRsZWQtZGF2cm9zLXNoYXJlZC1kaXJlY3Rvcnk6X0RnenNvblJnalluQ3JDc05RVG4tU0tlRndoTExCWUpibVZITHBUZ2UxYg==
Content-Length: 179
Connection: keep-alive

And, here's the response headers:

HTTP/1.1 207 Multi-Status
Access-Control-Allow-Origin: *
Vary: Authorization
Content-Security-Policy: default-src 'none'; sandbox
Content-Type: application/xml; charset=utf-8
Content-Encoding: gzip
Date: Sat, 22 Oct 2016 23:19:29 GMT
Connection: keep-alive
Transfer-Encoding: chunked

As you can see, the Content-Encoding is gzip, which happens to be unsupported by the client. Note that when I run the davros app locally outside sandstorm, I get identity encoding with no Content-Encoding header, and the client works.

For completeness, here are the headers for the same request from the un-sandboxed davros app:

HTTP/1.1 207 Multi-Status
X-Powered-By: Express
Access-Control-Allow-Methods: GET, HEAD, PUT, POST, DELETE, TRACE, OPTIONS, CONNECT, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, VERSION-CONTROL, REPORT, CHECKOUT, CHECKIN, UNCHECKOUT, MKWORKSPACE, UPDATE, LABEL, MERGE, BASELINE-CONTROL, MKACTIVITY, GETLIB
Access-Control-Max-Age: 86400
Access-Control-Allow-Headers: accept
Access-Control-Allow-Headers: accept-charset
Access-Control-Allow-Headers: accept-encoding
Access-Control-Allow-Headers: accept-language
Access-Control-Allow-Headers: authorization
Access-Control-Allow-Headers: content-length
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Headers: host
Access-Control-Allow-Headers: origin
Access-Control-Allow-Headers: proxy-connection
Access-Control-Allow-Headers: referer
Access-Control-Allow-Headers: user-agent
Access-Control-Allow-Headers: x-requested-with
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
content-type: application/xml; charset=utf-8
Vary: Brief,Prefer, Accept-Encoding
DAV: 1,3,extended-mkcol,2
Date: Sat, 22 Oct 2016 23:22:14 GMT
Connection: keep-alive
Transfer-Encoding: chunked
@kentonv
Copy link
Member

kentonv commented Oct 23, 2016

This seems to be the opposite bug of #2569, which complains that Sandstorm fails to pass through Accept-Encoding or to apply its own compression, hence lots of app assets aren't being properly compressed when they could be.

So... I can't really think of why you'd get a compressed result if the app isn't the one doing it. :/

@russellmcc
Copy link
Contributor Author

Okay, it looks like what's happening is that sandstorm is appending the Accept-Encoding headers before forwarding the request to the app. The app is then correctly encoding the file as gzip.

Here are the headers that the app sees:

connection: 'close',
  'content-type': 'application/xml;charset=utf-8',
  'content-length': '179',
  depth: '0',
  'accept-encoding': 'gzip',
  'x-sandstorm-tab-id': '921f66910a6ed9f5fa7db7351279d4e3',
  'x-sandstorm-username': 'Alice%20Dev%20Admin',
  'x-sandstorm-user-id': '5e0d06fefb17f641093c4686cf1fe597',
  'x-sandstorm-preferred-handle': 'alice',
  'x-sandstorm-user-picture': 'http://static.local.sandstorm.io:6080/identicon/5e0d06fefb17f641093c4686cf1fe597?s=256',
  'x-sandstorm-user-pronouns': 'female',
  'x-sandstorm-permissions': 'view,edit',
  host: 'sandbox',
  'x-sandstorm-session-id': '1',
  accept: '*/*'

Vs. the headers being sent to sandstorm:

Content-Type: text/xml
Depth: 0
Accept: */*
User-Agent: WebDAVFS/3.0.0 (03008000) Darwin/16.0.0 (x86_64)
Authorization: Basic dW50aXRsZWQtZGF2cm9zLXNoYXJlZC1kaXJlY3Rvcnk6X0RnenNvblJnalluQ3JDc05RVG4tU0tlRndoTExCWUpibVZITHBUZ2UxYg==
Content-Length: 179
Connection: keep-alive

I'm trying to figure out now at what layer the erroneous Accept-Encoding headers are being added.

@russellmcc
Copy link
Contributor Author

Looks like the http-bridge will indiscriminately add Accept-Encoding: gzip, see here:

lines.add(kj::str("Accept-Encoding: gzip"));

I think this probably isn't appropriate, unless we ensure that the client can accept gzip encoding.

@kentonv
Copy link
Member

kentonv commented Oct 23, 2016

Whoa. Now I'm really confused about #2569. I was observing no accept-encoding header being passed to Etherpad.

Looks like the line of code you found has been there since the very beginning.

I guess we need to change web-session.capnp to pass Accept-Encoding in WebSession::Context.

@ocdtrekkie
Copy link
Collaborator

I think I just hit this or something very related when troubleshooting a 403 Forbidden response from an app I'm working on, re: @timmc's experience in the linked Davros issue, a request in Firefox had the Accept-Encoding, but the response did not have a Content-Encoding header.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants