Nils,
On 9/24/20 13:29, Nils Breunese wrote:
> Christopher Schultz wrote:
>
>> On 9/24/20 07:46, Nils Breunese wrote:
>>> Mark Thomas wrote:
>>>
On 24/09/2020 11:02, Nils Breunese wrote:
> - Envoy allows the request based on the /v1/* rule, because it
> does not su
Mark,
On 9/24/20 12:41, Mark Thomas wrote:
> On 24/09/2020 17:28, Christopher Schultz wrote:
>
>
>
>> Tomcat will only use path parameters in the final segment of a URL e.g.
>> https://www.example.com/app/servlet;jsessionid=ABCD1234?q=search
>
> Not quite. Tomcat will only *add* the jsessionid
Christopher Schultz wrote:
> On 9/24/20 07:46, Nils Breunese wrote:
>> Mark Thomas wrote:
>>
>>> On 24/09/2020 11:02, Nils Breunese wrote:
>>>
>>>
>>>
- Envoy allows the request based on the /v1/* rule, because it
does not support path parameters, because they are not part of
On 24/09/2020 17:28, Christopher Schultz wrote:
> Tomcat will only use path parameters in the final segment of a URL e.g.
> https://www.example.com/app/servlet;jsessionid=ABCD1234?q=search
Not quite. Tomcat will only *add* the jsessionid at the end but it will
accept it on any segment.
Interna
Nils,
On 9/24/20 07:46, Nils Breunese wrote:
> Mark Thomas wrote:
>
>> On 24/09/2020 11:02, Nils Breunese wrote:
>>
>>
>>
>>> - Envoy allows the request based on the /v1/* rule, because it
>>> does not support path parameters, because they are not part of
>>> any recent standard (RFC 2396 drop
Mark Thomas wrote:
> On 24/09/2020 11:02, Nils Breunese wrote:
>
>
>
>> - Envoy allows the request based on the /v1/* rule, because it does not
>> support path parameters, because they are not part of any recent standard
>> (RFC 2396 dropped them in 1998 [1])
>
> Envoy does support path par
Martin Grigorov wrote:
> Someone else had the same/similar problem and the conclusion was that
> according to the Servlet specification this is the proper way to process
> the request - the request url should be normalized. If you need to protect
> some paths then you should do whatever is necess
Julian Reschke wrote:
> Am 24.09.2020 um 12:02 schrieb Nils Breunese:
>> Hello,
>>
>> I recently learned that when a server that supports path parameters [0] —
>> like Tomcat (I found Jetty also does) — is run behind a reverse proxy that
>> does path-based access control checks and does not su
Am 24.09.2020 um 12:02 schrieb Nils Breunese:
Hello,
I recently learned that when a server that supports path parameters [0] — like
Tomcat (I found Jetty also does) — is run behind a reverse proxy that does
path-based access control checks and does not support path parameters, your
combined s
On 24/09/2020 11:02, Nils Breunese wrote:
> - Envoy allows the request based on the /v1/* rule, because it does not
> support path parameters, because they are not part of any recent standard
> (RFC 2396 dropped them in 1998 [1])
Envoy does support path parameters and is correctly doing so in
On Thu, Sep 24, 2020 at 2:11 PM Martin Grigorov
wrote:
> Hi,
>
> On Thu, Sep 24, 2020 at 1:02 PM Nils Breunese wrote:
>
>> Hello,
>>
>> I recently learned that when a server that supports path parameters [0] —
>> like Tomcat (I found Jetty also does) — is run behind a reverse proxy that
>> does
Hi,
On Thu, Sep 24, 2020 at 1:02 PM Nils Breunese wrote:
> Hello,
>
> I recently learned that when a server that supports path parameters [0] —
> like Tomcat (I found Jetty also does) — is run behind a reverse proxy that
> does path-based access control checks and does not support path parameter
Hello,
I recently learned that when a server that supports path parameters [0] — like
Tomcat (I found Jetty also does) — is run behind a reverse proxy that does
path-based access control checks and does not support path parameters, your
combined setup could be vulnerable.
Consider this setup:
13 matches
Mail list logo
