Segfault when authorizing with HTTP proxy

[hagabaka]

When I use Squid HTTP/HTTPS proxy, fuse-google-drive segfaults near the end of the process (after outputing Connection #0 to host 127.0.0.1 left intact) and fails to mount. When I go without the proxy, it works correctly.

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0xb7f0874b in json_object_object_get () from /lib/libjson.so.0
(gdb) bt
#0  0xb7f0874b in json_object_object_get () from /lib/libjson.so.0
#1  0x08049ac7 in curl_post_callback (state=state@entry=0xbfffec34, 
    request=request@entry=0xbfffeb78) at gd_interface.c:146
#2  0x0804ab4c in gdi_init (state=state@entry=0xbfffec34) at gd_interface.c:488
#3  0x0804920a in main (argc=2, argv=0xbfffed44) at gd_fuse_operations.c:518

I can paste the output too, but I'm not sure if it contains any information about my account...

[jcline]

At first glance, it looks like it's not getting everything back from the request it makes or the JSON it gets is somehow malformed. I'm not terribly familiar with Squid, but I'm not sure why you would want to connect through it for this. All the requests are HTTPS, IIRC; I don't believe it can actually cache anything useful.

Anyway, something you could try is to add printf("%s", request->response.body.str); to the first line of curl_post_callback in gd_interface.c (~line 143). If you compare that output between connecting with and without squid, it should become apparent what isn't coming through correctly.

[hagabaka]

I just have Squid set as the default proxy through environmental variables and fuse-google-drive or libraries it uses picked it up. Below are last parts of the output when going through and without Squid. Is Squid returning the HTTP headers as part of the JSON content (between * Connection #0 to host 127.0.0.1 left intact and the real JSON)?

* upload completely sent off: 223 out of 223 bytes
< HTTP/1.1 200 OK
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Date: Sat, 11 Aug 2012 01:14:59 GMT
< Content-Type: application/json
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Server: GSE
< Transfer-Encoding: chunked
< 
* Connection #0 to host 127.0.0.1 left intact
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Date: Sat, 11 Aug 2012 01:14:59 GMT
Content-Type: application/json
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Transfer-Encoding: chunked

{
  "access_token" : "****",
  "token_type" : "Bearer",
  "expires_in" : 3600,
  "id_token" : "***",
  "refresh_token" : "***"
[1]    368 segmentation fault (core dumped)  fuse-google-drive ~/tmp/test1

* upload completely sent off: 223 out of 223 bytes
< HTTP/1.1 200 OK
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Date: Sat, 11 Aug 2012 01:15:45 GMT
< Content-Type: application/json
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Server: GSE
< Transfer-Encoding: chunked
< 
* Connection #0 to host accounts.google.com left intact
{
  "access_token" : "****",
  "token_type" : "Bearer",
  "expires_in" : 3600,
  "id_token" : "***",
  "refresh_token" : "****"
* Closing connection #0
}Authorization: OAuth ***
* About to connect() to docs.google.com port 443 (#0)
*   Trying 74.125.228.70...
* connected
* Connected to docs.google.com (74.125.228.70) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* SSL connection using ECDHE-RSA-RC4-SHA
* Server certificate:
*        subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=*.google.com
*        start date: 201
*        expire date: 201
*        subjectAltName: docs.google.com matched
*        issuer: C=U
*        SSL certificate verify ok.
> GET /feeds/default/private/full?v=3&showfolders=true&max-results=1000 HTTP/1.1
User-Agent: fuse-google-drive/0.1
Host: docs.google.com
Accept: */*
Authorization: OAuth ****

< HTTP/1.1 200 OK
< Content-Type: application/atom+xml; charset=UTF-8; type=feed
< Expires: Sat, 11 Aug 2012 01:15:46 GMT
< Date: Sat, 11 Aug 2012 01:15:46 GMT
< Cache-Control: private, max-age=0, must-revalidate, no-transform
< Vary: Accept, X-GData-Authorization, GData-Version
< GData-Version: 3.0
< ETag: W/"DUAAR3oycCt7ImA9WhJXFkk."
< Last-Modified: Sat, 11 Aug 2012 01:15:46 GMT
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Server: GSE
< Transfer-Encoding: chunked
< 
* Connection #0 to host docs.google.com left intact
* Closing connection #0

[jcline]

I modified your comment to remove the oauth tokens from the responses.

It appears as though the closing } is missing from the JSON. Offhand I don't see why that would be an issue with or without Squid... It's possible I have an off by one error somewhere, though.

[hagabaka]

Beside the closing }, the other difference I see is that the headers seemed to be printed back with Squid:

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Date: Sat, 11 Aug 2012 01:14:59 GMT
Content-Type: application/json
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Transfer-Encoding: chunked

[jcline]

Heh, yeah... Either of those could be adequate to break the JSON parsing.

I have an idea for a hack that might fix this most of the time, but I'm not sure what the root cause is to fix it completely. The hack would be to skip to the first instance of {, then parse the json from there to the end, adding a } if it doesn't exist.

Can't say I'm a huge fan of this solution, though. Maybe I'll setup Squid in a VM and see if I can come up with something better.

[luigibai]

Can you configure Squid not to emit the headers on the reply? Would http://www.squid-cache.org/Doc/config/reply_header_access/ help?