On 03/03/2017 08:30 AM, Eduard Bagdasaryan wrote:
> Any more suggestions/remarks here before this patch can be applied?
Just one: The patch breaks "make check" because some test cases use URI
schemes and, hence, require the new AnyP::UriScheme::Init() call. [I
cannot wait when we finally automate
Any more suggestions/remarks here before this patch
can be applied?
Thanks,
Eduard.
On 07.02.2017 18:10, Eduard Bagdasaryan wrote:
Checked that it is ok to move AnyP::UriScheme::Init() as
you suggested. Re-attached the patch (v5 r15037).
Eduard.
On 02.02.2017 22:12, Alex Rousskov wrote:
Checked that it is ok to move AnyP::UriScheme::Init() as
you suggested. Re-attached the patch (v5 r15037).
Eduard.
On 02.02.2017 22:12, Alex Rousskov wrote:
> We should avoid this code duplication [...]
> However, please check whether we can move the
> call up, to place it above
On 02/02/2017 05:53 AM, Eduard Bagdasaryan wrote:
> I applied your polishing suggestions to my latest patch
> re-attached it.
> +std::vector AnyP::UriScheme::LowercaseSchemeNames;
> +static std::vector LowercaseSchemeNames;
We should avoid this code duplication:
typedef std::vector
I applied your polishing suggestions to my latest patch
re-attached it.
Eduard.
On 02.02.2017 11:33, Amos Jeffries wrote:
On 1/02/2017 2:18 a.m., Eduard Bagdasaryan wrote:
Optimized with static array as you suggested and
re-attached the patch.
Thank you, looks like this one removes most
On 1/02/2017 2:18 a.m., Eduard Bagdasaryan wrote:
> Optimized with static array as you suggested and
> re-attached the patch.
>
Thank you, looks like this one removes most of the performance regression.
Just some polishing for src/anyp/UriScheme.cc ;
in AnyP::UriScheme::UriScheme
* this TODO
This is a bit improved version of previous patch:
fill static schemes array at configuration phase.
Eduard.
On 31.01.2017 16:18, Eduard Bagdasaryan wrote:
Optimized with static array as you suggested and
re-attached the patch.
Eduard.
On 30.01.2017 19:24, Alex Rousskov wrote:
On
Optimized with static array as you suggested and
re-attached the patch.
Eduard.
On 30.01.2017 19:24, Alex Rousskov wrote:
On 01/29/2017 07:10 AM, Amos Jeffries wrote:
I'm thinking the quick-and-dirty way is to just lowercase the 'proto'
variable in url.cc urlParse() function. Doing that in
On 01/29/2017 07:10 AM, Amos Jeffries wrote:
> I'm thinking the quick-and-dirty way is to just lowercase the 'proto'
> variable in url.cc urlParse() function. Doing that in the for-loop where
> it is copied from 'src' would be easiest.
> - it breaks the case preservation on unknown schemes a
> I'm thinking the quick-and-dirty way is to just lowercase the 'proto'
> variable in url.cc urlParse() function. Doing that in the for-loop where
> it is copied from 'src' would be easiest.
> - it breaks the case preservation on unknown schemes a litte bit. But
> since they are supposed to be
On 7/01/2017 5:41 a.m., Eduard Bagdasaryan wrote:
>
> On 06.01.2017 15:27, Amos Jeffries wrote:
>> As a result, the code responsible for lower-case
>>> transformation was not executed.
>>
>> That is intentional behaviour for several reasons;
>>
>> 1) it improves transparency and reduces risks
On 06.01.2017 15:27, Amos Jeffries wrote:
As a result, the code responsible for lower-case
transformation was not executed.
That is intentional behaviour for several reasons;
1) it improves transparency and reduces risks from proxy
fingerprinting by systems probing the URI scheme handling
On 2017-01-06 10:24, Eduard Bagdasaryan wrote:
Hello,
This patch fixes URI schemes to be case-insensitive (r14802
regression).
The bug was introduced by r14802 (better support of unknown
URL schemes). AnyP::UriScheme constructor had a problem: the
explicitly-specified img parameter (always
Hello,
This patch fixes URI schemes to be case-insensitive (r14802 regression).
The bug was introduced by r14802 (better support of unknown
URL schemes). AnyP::UriScheme constructor had a problem: the
explicitly-specified img parameter (always provided by URL::setScheme())
was used for all
14 matches
Mail list logo
