On Sat, Nov 06, 2021 at 07:02:39PM +, Stuart Henderson wrote:
> On 2021/11/06 17:29, Klemens Nanni wrote:
> > Encoding URL paths changes the requested URL and therefore may yield
> > different responses (opposed to an unencoded URL), solely depending on
> > how the server implements de/encoding
On 2021/11/06 17:29, Klemens Nanni wrote:
> Encoding URL paths changes the requested URL and therefore may yield
> different responses (opposed to an unencoded URL), solely depending on
> how the server implements de/encoding.
Makes sense as this matches what various other tools that fetch URLs do
On Sat, Nov 06, 2021 at 11:33:21AM -0600, Theo de Raadt wrote:
> > This matches exactly what is seen on the wire, e.g. with tshark(1).
>
> I don't see why this is important. Users don't need to see what is
> on the wire.
>
> Why intentionaly expose them to a translation they are not supposed
> t
> This matches exactly what is seen on the wire, e.g. with tshark(1).
I don't see why this is important. Users don't need to see what is
on the wire.
Why intentionaly expose them to a translation they are not supposed
to know or care about?
Encoding URL paths changes the requested URL and therefore may yield
different responses (opposed to an unencoded URL), solely depending on
how the server implements de/encoding.
Thus it is imperative to inform users about the factually requested URL
in case servers behave unexpectedly. Consider
