Opened 2 years ago

Last modified 14 months ago

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

https://codereview.adblockplus.org/29377775

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.

Change History (16)

comment:1 Changed 23 months ago 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: https://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/#the-setrequestheader-method

Last edited 23 months ago by fhd (previous) (diff)

comment:2 Changed 23 months ago by fhd

  • Priority changed from Unknown to P3
  • Ready set

comment:3 Changed 23 months ago 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 23 months ago by hfiguiere

Part 1, CURL implementation, currently on codereview:
https://codereview.adblockplus.org/29377775

comment:5 Changed 23 months ago by hfiguiere

  • Owner set to hfiguiere

comment:6 Changed 23 months ago by hfiguiere

  • Status changed from new to reviewing

comment:7 Changed 23 months ago by hfiguiere

  • Review URL(s) modified (diff)

comment:8 follow-up: Changed 23 months ago by hfiguiere

  • Review URL(s) modified (diff)

Added header filtering for the XMLHttpRequest. With tests.
https://codereview.adblockplus.org/29377825

comment:9 Changed 23 months ago by hfiguiere

  • Blocking 4951 added

comment:10 in reply to: ↑ 8 Changed 23 months ago 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 23 months ago by hfiguiere

  • Review URL(s) modified (diff)

comment:12 Changed 23 months ago by abpbot

A commit referencing this issue has landed:
Issue 4916 - Request compression in CURL WebRequest.

comment:13 Changed 23 months ago 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 23 months ago by hfiguiere

  • Blocking 4951 removed

comment:15 Changed 14 months ago 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 14 months ago by sergz

Under it's rather a configuration I expect that merely adding of WINHTTP_OPTION_DECOMPRESSION will allow to achieve the goal.

Note: See TracTickets for help on using tickets.