Opened on 02/20/2017 at 02:17:17 PM
Last modified on 11/18/2017 at 02:43:02 PM
#4916 reopened change
look into the way to accept compressed data in network requests on Windows
| Reported by: | sergz | Assignee: | |
|---|---|---|---|
| Priority: | P3 | Milestone: | |
| Module: | Libadblockplus | Keywords: | |
| Cc: | fhd | Blocked By: | |
| Blocking: | Platform: | Unknown / Cross platform | |
| Ready: | yes | Confidential: | no |
| Tester: | Unknown | Verified working: | no |
| Review URL(s): | |||
Description
Background
Currently, it seems we don't use compression to download subscriptions, however, it could save the traffic with the factor 10 (5MB of uncompressed vs 0.5 MB of compressed data).
What to to
- check what is actually sent on different platforms (android, windows, etc) and put the result here (most likely it's uncompressed because we don't set corresponding headers).
- ensure that we use compression on platforms mentioned above.
Attachments (0)
Change History (16)
comment:1 Changed on 03/01/2017 at 09:49:28 AM by fhd
comment:2 Changed on 03/01/2017 at 09:53:33 AM by fhd
- Priority changed from Unknown to P3
- Ready set
comment:3 Changed on 03/01/2017 at 10:50:31 AM by sergz
Just in case, since we still support Windows XP, I think we can simply exclude that feature for it because in this case we won't have to fiddle with manual decompression. On other MS Windows and androids it should be flawless to add a support of decompression, it's rather a configuration than implementation of something.
comment:4 Changed on 03/01/2017 at 10:49:41 PM by hfiguiere
Part 1, CURL implementation, currently on codereview:
https://codereview.adblockplus.org/29377775
comment:5 Changed on 03/01/2017 at 11:35:12 PM by hfiguiere
- Owner set to hfiguiere
comment:6 Changed on 03/01/2017 at 11:35:27 PM by hfiguiere
- Status changed from new to reviewing
comment:8 follow-up: ↓ 10 Changed on 03/02/2017 at 09:17:38 PM by hfiguiere
- Review URL(s) modified (diff)
Added header filtering for the XMLHttpRequest. With tests.
https://codereview.adblockplus.org/29377825
comment:9 Changed on 03/03/2017 at 01:42:16 PM by hfiguiere
- Blocking 4951 added
comment:10 in reply to: ↑ 8 Changed on 03/03/2017 at 01:46:56 PM by hfiguiere
Replying to hfiguiere:
Added header filtering for the XMLHttpRequest. With tests.
https://codereview.adblockplus.org/29377825
This was moved to bug #4951
comment:11 Changed on 03/03/2017 at 01:47:13 PM by hfiguiere
- Review URL(s) modified (diff)
comment:12 Changed on 03/06/2017 at 08:23:08 AM by abpbot
A commit referencing this issue has landed:
Issue 4916 - Request compression in CURL WebRequest.
comment:13 Changed on 03/06/2017 at 01:20:04 PM by hfiguiere
- Owner hfiguiere deleted
CURL implementation has landed. The windows implementation must be done. I can't do that right now. Unassigning myself.
comment:14 Changed on 03/09/2017 at 04:49:48 PM by hfiguiere
- Blocking 4951 removed
comment:15 Changed on 11/18/2017 at 06:27:09 AM by oleksandr
- Status changed from reviewing to reopened
- Summary changed from look into the way to accept compressed data in network requests to look into the way to accept compressed data in network requests on Windows
comment:16 Changed on 11/18/2017 at 02:43:02 PM by sergz
Under it's rather a configuration I expect that merely adding of WINHTTP_OPTION_DECOMPRESSION will allow to achieve the goal.
How I see it, this boils down to setting the Accept-Encoding header. What encoding we can accept depends on the specific WebRequest implementation, however... So it seems the right way to solve this is to set the header in all the implementations. We have DefaultWebRequestCurl and DefaultWebRequestWinInet in Libadblockplus, and AndroidWebRequest in Libadblockplus-Android. Since the last one is in another module, we'll need a separate issue for that.
While at it, we might want to reject Accept-Encoding and the other headers that cannot be set in XMLHttpRequest according to the spec: https://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/#the-setrequestheader-method