baranyaib90

Results 30 comments of baranyaib90

false means, that it's not used by default. The proxy uses HTTP/2.0 by default, and with -x/-q you can choose to use HTTP 1.1/3 You can check the used protocol...

Hi, the current code on master does compile and work with curl 7.82.0 and HTTP/3 support. Please check this commit: https://github.com/baranyaib90/https_dns_proxy/commit/ee40455be63957626ffc7e669978ac85c9318f91 I was using Ubuntu 20.04 and worked perfectly. When...

About latency: - If all libraries are compiled in debug mode (and not in release) it's not so surprising. - If libcurl always exchanges new encryption key at the beginning...

[Haru202](https://github.com/Haru202) you are right, with debug curl build, latency is strange: - HTTP/2 is around 70 ms in average for me - HTTP/3 is more like 200-300 ms typically Sadly...

Hi, I understand your issue and it's valid. I wrote my answers according my knowledge. (I'm not speaking in @aarond10 name.) 1. There is no plan to support TCP DNS...

Hi, [stuff](https://openwrt.org/docs/guide-developer/packages#use_source_repository) is understandable from OpenWRT PoV. But from this project PoV I wanted to have automated version generation instead of some "maintained by hand" version file. I need to...

@stangri as a (long term) work around, you could extend your current patch [010-fix-cmakelists.patch](https://github.com/openwrt/packages/blob/master/net/https-dns-proxy/patches/010-fix-cmakelists.patch) with this https://github.com/baranyaib90/https_dns_proxy/commit/2ca80486ba6a4e5acbdf0ff581d9754af17fa33b so you can use `CMAKE_OPTIONS += -DCLANG_TIDY_EXE= -DGIT_VERSION=2022.10.15-f52a85`

I don't know yet, if I will propose this in a later pull request or not. At least you have the work-around for OpenWRT build. As I wrote before, I'm...

Seems like same issue as: https://github.com/facebook/folly/issues/601

Hi, use the work-around I wrote here: https://github.com/facebook/folly/issues/601#issuecomment-347100410 This problem should be resolved in libev library to separate libevent wrapper to a separate library. But as I see, it's not...