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):



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

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:

Last edited on 03/01/2017 at 09:53:06 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:

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:7 Changed on 03/01/2017 at 11:41:09 PM by hfiguiere

  • Review URL(s) modified (diff)

comment:8 follow-up: 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.

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.

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.

Add Comment

Modify Ticket

Change Properties
as reopened .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from (none).
Next status will be 'reviewing'.
Note: See TracTickets for help on using tickets.