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

Certain traffics get corrupted #1452

Closed
theseanl opened this issue Dec 14, 2016 · 10 comments

Comments

@theseanl
Copy link

commented Dec 14, 2016

Original thread: https://forum.adguard.com/index.php?threads/electricquilt-com.17567/

STR:

  1. go to http://electricquilt.com/online-shop/electric-quilt-7/
  2. Select any option of the product (e.g. Mac Download $189.95)
  3. Click on "Add to Cart" button.

Then a browser tries to download an application/octet-stream file with no name.

  • This is reproduced with all browsers that I've tested.
  • Applying exception rules to certain requests does not resolve the problem.
  • If I exclude the browser from "filtered apps" section, the website works as intended.
  • If Fiddler is being openned and capturing traffics, the website works as intended.
@ameshkov ameshkov added this to the 6.2 milestone Dec 19, 2016
@ameshkov ameshkov added the bug label Dec 19, 2016
@msigley

This comment has been minimized.

Copy link

commented Jan 23, 2017

Any progress on this? I have had this issue open in my internal bug tracker for over a month now.

@ameshkov ameshkov modified the milestones: 6.1 R3, 6.2 Jan 26, 2017
@ameshkov ameshkov modified the milestones: 6.2, 6.1 R3 Jan 26, 2017
@ameshkov

This comment has been minimized.

Copy link
Member

commented Jan 26, 2017

The server sends an invalid response.

Request:

POST electricquilt.com/online-shop/cart/ HTTP/1.1
Host: electricquilt.com
Connection: keep-alive
Content-Length: 114
Cache-Control: max-age=0
Origin: http://electricquilt.com
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: http://electricquilt.com/online-shop/electric-quilt-7/
Accept-Encoding: gzip, deflate
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: PHPSESSID=7rsj2u9fa1n8om6mhk4a8a76i3; funmodal-donot-show-again=0; flag-status=show

Response:

HTTP/1.1 302 Moved Temporarily
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Location: http://electricquilt.com/online-shop/cart/
Server: EQ Web Server
X-Pingback: http://electricquilt.com/xmlrpc.php
Refresh: 0;url=http://electricquilt.com/online-shop/cart/
X-Powered-By: Blood, Sweat, and Tears
Date: Thu, 26 Jan 2017 10:06:26 GMT

Content length should be zero, but then server sends response content:

<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF="http: //electricquilt.com/online-shop/cart/">here</a></body>
@ameshkov

This comment has been minimized.

Copy link
Member

commented Jan 26, 2017

Possible solution: shut connection down in case of response violating HTTP protocol. We should think about other options though.

@confessor-adguard

This comment has been minimized.

Copy link

commented Jan 27, 2017

Please note that this problem affects Adguard for Mac too.

@ameshkov

This comment has been minimized.

Copy link
Member

commented Jan 27, 2017

I guess it affects AG for Android as well.

@ameshkov ameshkov modified the milestones: 6.1 R3, 6.2 Feb 1, 2017
@adbuker

This comment has been minimized.

Copy link

commented Feb 1, 2017

ADWIN-CR-122

@msigley

This comment has been minimized.

Copy link

commented Feb 1, 2017

So does this mean this issue is resolved?

The returning content on redirect responses is a default IIS + FastCGI behavior.

@ameshkov

This comment has been minimized.

Copy link
Member

commented Feb 1, 2017

So does this mean this issue is resolved?

Yeah, we'll handle it properly starting from v6.1R3.

The returning content on redirect responses is a default IIS + FastCGI behavior.

Returning content is not a problem.

What's wrong is that response headers contain Content-Length: 0 at the same time.

@msigley

This comment has been minimized.

Copy link

commented Feb 1, 2017

Well if you are emulating browser behavior. If the content length is 0 you simply ignore the content.

@ameshkov

This comment has been minimized.

Copy link
Member

commented Feb 2, 2017

Well if you are emulating browser behavior. If the content length is 0 you simply ignore the content.

The problem is that connection was kept alive.

Here's what happens inside of a single connection:

  1. Client: Sends request
  2. Client: Awaits for response
  3. Server: Sends response with Content-Length: 0
  4. Server: Sends response body
  5. Client: Reads response headers (not content as content length is 0)
  6. Client: Sends next request
  7. Client: Starts reading a response to the next request; gets previous response body instead; closes connection due to protocol violation.

Browser detects protocol violation earlier, in step 4. The problem was that with Adguard browser didn't know that server has violated protocol unless AG gets to step 7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.