You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Garret Wilson <ga...@globalmentor.com> on 2019/02/03 21:20:33 UTC
latest situation with escaped path delimiters in URI
Hi, all. I've stumbled on a situation I need some clarity on. As is
typical, there's all sorts of information floating around, most of it
more than a decade old, with no indication of what the current status is.
Our team is creating a RESTful API (using JAX-RS implemented by
RESTEasy) to a general semantic framework in which each "thing" is
identified by a URI. (The framework is URF <https://urf.io/>, but that's
a story for another day. It's analogous to RDF.) Basically we want to
issue a GET to https://example.com/{thingURI}/description to get back
info about the "thing".
If we want to look up the thing identified by
https://example.info/foobar, we would need to issue a request to
https://example.com/https%3A%2F%2Fexample.info%2Ffoobar/description .
That should be completely legal and spec-compliant, and has been since
web time began.
You no doubt already know the problem: Tomcat won't allow encoded
slashes unless one sets system property
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH to true.
Apparently this there was a bug somewhere in Tomcat 6
<https://tomcat.apache.org/security-6.html#Apache_Tomcat_6.x_vulnerabilities>
(back in 2007!) when used behind a proxy, as Mark explained on Stack
Overflow <https://stackoverflow.com/a/19584499/421049>. Tomcat 6 is
really old, and Mark's Stack Overflow message seems to hint that it's
not an issue anymore.
I'm not one to blindly change a setting unless I know what it's doing,
and complain/advocate for change if it's no longer relevant. So I'm full
of questions:
* Is this even an issue anymore? Of not, is there a reason not to make
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH default to true?
* If this setting is still needed in some cases, is there any way to
control it without resorting to a system property? (System
properties are not very flexible, and Tomcat has many layers of more
manipulable settings, as you all would know better than me.)
* If we enable encoded slashes in Tomcat, do we need to do anything in
Apache to get this to work if we put it in front of Tomcat? One
really old Stack Overflow post
<https://stackoverflow.com/a/4443129/421049> indicated that there
used to be a bug with AllowEncodedSlashes not being inherited by
Apache virtual hosts. See also
https://issues.sonatype.org/browse/NEXUS-10570 .
* Do we need special configuration of mod_kj? (I haven't connected
Apache to Tomcat in a while; I'm not sure the current best
practices. I'll have to read up on that.) The connectors
documentation
<https://tomcat.apache.org/connectors-doc/reference/apache.html> is
mentioning things like ForwardURIEscaped, which looks like it may be
related.
I'm not even sure I asked all the right questions, but basically: I want
to uses encoded slashes in my request URIs. What's the latest situation
on that?
Thanks in advance,
Garret
Re: latest situation with escaped path delimiters in URI
Posted by Garret Wilson <ga...@globalmentor.com>.
On 2/5/2019 1:15 PM, Mark Thomas wrote:
> …
> Migratation to git has been in planning for a while. We are pretty much
> ready to pull the trigger. It is largely waiting for someone to have the
> time to do it when there aren't other more urgent things to be dealt
> with. I'd expect it to happen in the next few months.
That would really be super. If there are discussions that will help move
this forward, I would like to contribute (to the discussions, at least)
if it's helpful. About three years ago I migrated over a decade of my
Subversion code to Git, and I did a lot of research on some of the
gotchas. It involved splitting out branches and changing their roots.
Here's the resulting script I used:
https://bitbucket.org/globalmentor/util/src/master/bin/svn2git.sh (with
related scripts in the same repo).
A not-unimportant factor is the whole LF vs CRLF nightmare. If you
haven't been normalizing to LF in the Subversion repo from day one,
you'll want to rewrite the entire Git history normalizing the text files
(including source code) before using the repository. You'll want to add
a good `.gitattributes` file so that this happens automatically going
forward. (I understand you have this to some extent in Subversion
already, but it's not as configurable as with `.gitattributes`.) Anyway,
I hope you can go forward with this soon.
> However, you can still use git and GitHub and provide PRs against
> gitub.com/apache/tomcat The ASF has integrations in place that make it
> fairly easy for us to pull those in.
Oh, that's nice. Good news. OK, I'll start looking at the code, thanks.
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: latest situation with escaped path delimiters in URI
Posted by Mark Thomas <ma...@apache.org>.
On 05/02/2019 14:51, Garret Wilson wrote:
> On 2/3/2019 9:34 PM, Mark Thomas wrote:
>>
>>> * If this setting is still needed in some cases, is there any way to
>>> control it without resorting to a system property? (System
>>> properties are not very flexible, and Tomcat has many layers of more
>>> manipulable settings, as you all would know better than me.)
>> No. Moving system properties to more fine-grained configuration
>> locations is on the TODO list.
>
>
> Is there really an actual to-do list, or were you speaking
> metaphorically? I'd be interested in looking at it.
https://svn.apache.org/viewvc/tomcat/trunk/TOMCAT-NEXT.txt?view=annotate
> I was crossing my fingers that https://github.com/apache/tomcat would
> actually be using the issue tracker, and that would be the to-do list,
> but I suppose I was expecting too much. Speaking of which, is the GitHub
> repository the canonical place for source code?
No. It is a mirror of svn.
> Because
> https://tomcat.apache.org/svn.html claims that Tomcat still uses
> Suversion and that Git is just a read-only mirror, even though
> https://git.apache.org/ claims that some projects have switched to
> GitHub for their primary SCM.
Those statements are all correct.
> I'm really interested in contributing, but I shudder at thinking about
> regressing a decade to start messing with Subversion (just
> `.gitattributes and how it more or less fixes the CRLF nightmare is a
> huge thing) and submitting patches rather than commenting on pull
> requests. (I have nothing against Subversion, mind you. I thought it was
> wonderful and I once used the property system extensively for per-file
> metadata in a custom CRM. But for a SCM… the world has moved on.) What's
> the Tomcat source code status?
Migratation to git has been in planning for a while. We are pretty much
ready to pull the trigger. It is largely waiting for someone to have the
time to do it when there aren't other more urgent things to be dealt
with. I'd expect it to happen in the next few months.
However, you can still use git and GitHub and provide PRs against
gitub.com/apache/tomcat The ASF has integrations in place that make it
fairly easy for us to pull those in.
> Returning to the subject, do you have a list of system properties you'd
> be interested in making configurable,
All of them ;)
http://tomcat.apache.org/tomcat-9.0-doc/config/systemprops.html
Some are going to be a lot easier to address than others. I suspect that
in some cases we'd opt to keep the system property due to the complexity
of replacing it.
> and would this be a welcome
> contribution?
Yes.
> Where in the code code I look before committing myself?
Pick a property and use your IDE (or GitHub, or ...) to see how it is
used. Then figure out where to put the replacement configuration. Ask on
dev@ if pointers are required.
Note: In terms of backward compatibility, we have typically used the
system property to set the default of the new config option and then
dropped the system property in a subsequent major release.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: latest situation with escaped path delimiters in URI
Posted by Garret Wilson <ga...@globalmentor.com>.
On 2/3/2019 9:34 PM, Mark Thomas wrote:
>
>> * If this setting is still needed in some cases, is there any way to
>> control it without resorting to a system property? (System
>> properties are not very flexible, and Tomcat has many layers of more
>> manipulable settings, as you all would know better than me.)
> No. Moving system properties to more fine-grained configuration
> locations is on the TODO list.
Is there really an actual to-do list, or were you speaking
metaphorically? I'd be interested in looking at it.
I was crossing my fingers that https://github.com/apache/tomcat would
actually be using the issue tracker, and that would be the to-do list,
but I suppose I was expecting too much. Speaking of which, is the GitHub
repository the canonical place for source code? Because
https://tomcat.apache.org/svn.html claims that Tomcat still uses
Suversion and that Git is just a read-only mirror, even though
https://git.apache.org/ claims that some projects have switched to
GitHub for their primary SCM.
I'm really interested in contributing, but I shudder at thinking about
regressing a decade to start messing with Subversion (just
`.gitattributes and how it more or less fixes the CRLF nightmare is a
huge thing) and submitting patches rather than commenting on pull
requests. (I have nothing against Subversion, mind you. I thought it was
wonderful and I once used the property system extensively for per-file
metadata in a custom CRM. But for a SCM… the world has moved on.) What's
the Tomcat source code status?
Returning to the subject, do you have a list of system properties you'd
be interested in making configurable, and would this be a welcome
contribution? Where in the code code I look before committing myself?
Cheers,
Garret
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: latest situation with escaped path delimiters in URI
Posted by Mark Thomas <ma...@apache.org>.
On 03/02/2019 23:58, Garret Wilson wrote:
> On 2/3/2019 3:34 PM, Mark Thomas wrote:
>> ...
>> There is an open question what Tomcat should do with %2F sequences.
>
> "What Tomcat should do" in what context? The servlet and JAX-RS specs
> may be clear about whether decoded or "raw" APIs should be returned from
> the various API methods. But I guess the issue here is /not/ whether
> JAX-RS should interpret a path segment as decoded or encoded. The issue
> is whether Tomcat has already fiddled with the URI itself to /change
> what constitutes the path segment/.
The Servlet spec is not always clear whether a URI or path that is
returned should be:
- %nn decoded or not
- normalized or not
This gets interesting because if servlet mappings, filter mappings,
security constraints (and all other URI pattern / path) based
configuration don't use a canonical form (i.e. always decoded, always
normalized) then you open up all sorts of issues such as security
constraint bypass.
e.g. if
/private
is protected by security constraints, a request to
/foo/../private
or
/priv%61te
should be subject to the same constraints. Hence you need to normalise
and decode before mapping the request. The question then becomes what to
return for getServletPath(), getPathInfo() and friends?
Tomcat takes the view that since only getRequestURI() states that the
return value is not decoded, all other return values are decoded. Tomcat
also normalises those values.
> Unless an EE specification says to muck around with the URI like this, I
> don't see how the server has any business changing the content of the
> URI. If the escaped path delimiters are decoded early on, then the
> downstream APIs will get different path segments altogether: some will
> have characters missing, and there will moreover be additional path
> segments than intended. It would seem to be that "trying to be helpful
> without being asked" in this case (as in most cases) would probably
> raise security issues, too.
>
> Further downstream, whether each API method returns encoded or decoded
> information would depend on what the API contracts say, for better or
> for worse.
>
>
>> It
>> currently decodes them. Arguably, it should leave them alone.
>
> That sounds right to me.
The problem is 15+ years of doing something else. Every time we make a
change to this sort of thing - even if is 100% backed by specs that have
been not changed during the lifetime of Tomcat - it ends up breaking
something for some users that rely on the incorrect behaviour.
I'm hoping to get clarification from the Servlet EG for the next release
of the Servlet spec.
https://github.com/eclipse-ee4j/servlet-api/issues/18
My current thinking (assuming no movement from the Servlet EG) is that
we add an option to Tomcat to control the %nn decoding of reserved
characters with if defaulting to "decode" in 9.0.x (for backwards
compatibility) and changing to "not decode" for 10.0.x onwards.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: latest situation with escaped path delimiters in URI
Posted by Garret Wilson <ga...@globalmentor.com>.
On 2/3/2019 3:34 PM, Mark Thomas wrote:
> ...
> There is an open question what Tomcat should do with %2F sequences.
"What Tomcat should do" in what context? The servlet and JAX-RS specs
may be clear about whether decoded or "raw" APIs should be returned from
the various API methods. But I guess the issue here is /not/ whether
JAX-RS should interpret a path segment as decoded or encoded. The issue
is whether Tomcat has already fiddled with the URI itself to /change
what constitutes the path segment/.
Unless an EE specification says to muck around with the URI like this, I
don't see how the server has any business changing the content of the
URI. If the escaped path delimiters are decoded early on, then the
downstream APIs will get different path segments altogether: some will
have characters missing, and there will moreover be additional path
segments than intended. It would seem to be that "trying to be helpful
without being asked" in this case (as in most cases) would probably
raise security issues, too.
Further downstream, whether each API method returns encoded or decoded
information would depend on what the API contracts say, for better or
for worse.
> It
> currently decodes them. Arguably, it should leave them alone.
That sounds right to me.
I'll read the link you sent, thanks.
Garret
Re: latest situation with escaped path delimiters in URI
Posted by Mark Thomas <ma...@apache.org>.
On 03/02/2019 21:20, Garret Wilson wrote:
> Hi, all. I've stumbled on a situation I need some clarity on. As is
> typical, there's all sorts of information floating around, most of it
> more than a decade old, with no indication of what the current status is.
>
> Our team is creating a RESTful API (using JAX-RS implemented by
> RESTEasy) to a general semantic framework in which each "thing" is
> identified by a URI. (The framework is URF <https://urf.io/>, but that's
> a story for another day. It's analogous to RDF.) Basically we want to
> issue a GET to https://example.com/{thingURI}/description to get back
> info about the "thing".
>
> If we want to look up the thing identified by
> https://example.info/foobar, we would need to issue a request to
> https://example.com/https%3A%2F%2Fexample.info%2Ffoobar/description .
> That should be completely legal and spec-compliant, and has been since
> web time began.
>
> You no doubt already know the problem: Tomcat won't allow encoded
> slashes unless one sets system property
> org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH to true.
> Apparently this there was a bug somewhere in Tomcat 6
> <https://tomcat.apache.org/security-6.html#Apache_Tomcat_6.x_vulnerabilities>
> (back in 2007!) when used behind a proxy, as Mark explained on Stack
> Overflow <https://stackoverflow.com/a/19584499/421049>. Tomcat 6 is
> really old, and Mark's Stack Overflow message seems to hint that it's
> not an issue anymore.
>
> I'm not one to blindly change a setting unless I know what it's doing,
> and complain/advocate for change if it's no longer relevant. So I'm full
> of questions:
>
> * Is this even an issue anymore? Of not, is there a reason not to make
> org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH default to true?
Yes it can be an issue. It all depends on the behaviour / configuration
of the reverse proxy. You need to make sure that proxy passes the URI
exactly as it received it. If it decoding %nn sequences then at best
things will break. At worst you may have security issues.
> * If this setting is still needed in some cases, is there any way to
> control it without resorting to a system property? (System
> properties are not very flexible, and Tomcat has many layers of more
> manipulable settings, as you all would know better than me.)
No. Moving system properties to more fine-grained configuration
locations is on the TODO list.
> * If we enable encoded slashes in Tomcat, do we need to do anything in
> Apache to get this to work if we put it in front of Tomcat? One
> really old Stack Overflow post
> <https://stackoverflow.com/a/4443129/421049> indicated that there
> used to be a bug with AllowEncodedSlashes not being inherited by
> Apache virtual hosts. See also
> https://issues.sonatype.org/browse/NEXUS-10570 .
I'm not sure.
> * Do we need special configuration of mod_jk? (I haven't connected
> Apache to Tomcat in a while; I'm not sure the current best
> practices. I'll have to read up on that.) The connectors
> documentation
> <https://tomcat.apache.org/connectors-doc/reference/apache.html> is
> mentioning things like ForwardURIEscaped, which looks like it may be
> related.
Make sure you use the latest release.
Read the forwarding section carefully.
I think you'll want ForwardURICompatUnparsed
> I'm not even sure I asked all the right questions, but basically: I want
> to uses encoded slashes in my request URIs. What's the latest situation
> on that?
This might be useful background reading:
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459
There is an open question what Tomcat should do with %2F sequences. It
currently decodes them. Arguably, it should leave them alone. That might
end up being a new configuration option.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: latest situation with escaped path delimiters in URI
Posted by Rainer Jung <ra...@kippdata.de>.
Am 03.02.2019 um 22:20 schrieb Garret Wilson:
> Hi, all. I've stumbled on a situation I need some clarity on. As is
> typical, there's all sorts of information floating around, most of it
> more than a decade old, with no indication of what the current status is.
>
> Our team is creating a RESTful API (using JAX-RS implemented by
> RESTEasy) to a general semantic framework in which each "thing" is
> identified by a URI. (The framework is URF <https://urf.io/>, but that's
> a story for another day. It's analogous to RDF.) Basically we want to
> issue a GET to https://example.com/{thingURI}/description to get back
> info about the "thing".
>
> If we want to look up the thing identified by
> https://example.info/foobar, we would need to issue a request to
> https://example.com/https%3A%2F%2Fexample.info%2Ffoobar/description .
> That should be completely legal and spec-compliant, and has been since
> web time began.
>
> You no doubt already know the problem: Tomcat won't allow encoded
> slashes unless one sets system property
> org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH to true.
> Apparently this there was a bug somewhere in Tomcat 6
> <https://tomcat.apache.org/security-6.html#Apache_Tomcat_6.x_vulnerabilities>
> (back in 2007!) when used behind a proxy, as Mark explained on Stack
> Overflow <https://stackoverflow.com/a/19584499/421049>. Tomcat 6 is
> really old, and Mark's Stack Overflow message seems to hint that it's
> not an issue anymore.
>
> I'm not one to blindly change a setting unless I know what it's doing,
> and complain/advocate for change if it's no longer relevant. So I'm full
> of questions:
>
> * Is this even an issue anymore? Of not, is there a reason not to make
> org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH default to
> true?
> * If this setting is still needed in some cases, is there any way to
> control it without resorting to a system property? (System
> properties are not very flexible, and Tomcat has many layers of more
> manipulable settings, as you all would know better than me.)
> * If we enable encoded slashes in Tomcat, do we need to do anything in
> Apache to get this to work if we put it in front of Tomcat? One
> really old Stack Overflow post
> <https://stackoverflow.com/a/4443129/421049> indicated that there
> used to be a bug with AllowEncodedSlashes not being inherited by
> Apache virtual hosts. See also
> https://issues.sonatype.org/browse/NEXUS-10570 .
Looking at the code in server/core.c in the current 2.4.x, merging
config is implemented in merge_core_dir_configs() and indeed the
sessiongs for AllowEncodedSlashes are not inherited from the global
server into virtual hosts but instead overwritten by what is set in the
virtual host inluding its default values. So yes, you need to explicitly
set it in virtual hosts. This has been fixed in trunk in 2013
(r1496339), but was not ported back to 2.4 probably due to compatibility
reasons.
> * Do we need special configuration of mod_kj? (I haven't connected
> Apache to Tomcat in a while; I'm not sure the current best
> practices. I'll have to read up on that.) The connectors
> documentation
> <https://tomcat.apache.org/connectors-doc/reference/apache.html> is
> mentioning things like ForwardURIEscaped, which looks like it may be
> related.
In addition to Mark's response: once your web server config needs to
change the original URL, e.g. by mod_rewrite, it will likely decode at
least parts of the URL to operate on a normalized URL. Once that
happens, there's no obvious way back to an encoded URL that is
consistent with the original one. Encoding is not really the reverse of
decoding, eg. when a character does not have to be encoded, but was
encoded in the original URL, the sequence decode then encode will not
encode it back.
You might want to set AllowEncodedSlashes NoDecode and test it.
See http://tomcat.apache.org/connectors-doc/common_howto/proxy.html,
especially "URL Encoding" and for details of some of the
non-recommeneded options
http://tomcat.apache.org/connectors-doc/reference/apache.html especially
"Forwarding".
> I'm not even sure I asked all the right questions, but basically: I want
> to uses encoded slashes in my request URIs. What's the latest situation
> on that?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: latest situation with escaped path delimiters in URI
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Garret,
On 2/4/19 17:22, Garret Wilson wrote:
> On 2/4/2019 7:31 PM, Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> Garret,
>>
>> On 2/3/19 16:20, Garret Wilson wrote:
>>> If we want to look up the thing identified by
>>> https://example.info/foobar, we would need to issue a request
>>> to
>>> https://example.com/https%3A%2F%2Fexample.info%2Ffoobar/description
>>
>>>
Why
>> are you %-encoding the slashes at all? They are perfectly legal
>> as-is.
>
>
> Hmmm… So let's say my RESTful API endpoint is
> https://example.com/{thingURI}/description as I mentioned. (Yes, I
> know that RESTful APIs don't have to be meaningful or structured as
> long as we use HATEOAS, but… a lot of us like them.) So you're
> saying that to request information for the resource
> https://example.info/foobar, I would send a GET request to:
>
> https://example.com/https%3A//example.info/foobar/description
>
> That raises all sorts of questions, such as
>
> * The double slash is OK? Really!?? * Is there any RESTful API
> framework on the planet that would realize the URI path
> "/https%3A//example.info/foobar/description" matched
> "{thingURI}/description"? So if I'm using JAX-RS with a
> @Path("{thingURI}/description") with a string
> @PathParam("thingURI") thing, JAX-RS would set the "thing"
> parameter to "https://example.info/foobar"?? I highly doubt that.
I've never used a RESTful API framework, but you can always pull the
full URI from a request and do whatever you want with it.
> Either I'm missing something and I'm going to learn something cool;
> or you missed some of the details of what I wrote. :) If I'm
> missing something, please explain because I'm ready to learn!
No, I got it. I just didn't realize that the opaqueness of the
{thingURI} had to be ... so opaque.
The only problem you are running into is the inertia of history.
http://example.com/foo%2fbar has sometimes been interpreted to mean
the same thing as http://example.com/foo/bar even though it should
never have been so. Erring on the side of security seems to be a Good
Thing these days.
If your application isn't rendered insecure by setting
ALLOW_ENCODED_SLASH=true, then by all means, use it.
As for not setting it for the whole server, that's hard to do, since
the URL-decoding must happen before the request is mapped to a
particular application.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxZpQsACgkQHPApP6U8
pFgIURAAkpcL2vbU74izgIIabjQaMw0bN8edMG4kiPNJYlzGha+FE0IrFopywXAP
Cihmt108aW3toFyNhFEB+4VtuNtMFN2zz+wtLijZX9+rcn8v/W06Ya06BR62IvNz
m4/S3kB0wWEIynktB935qmh+KqVmVfcyEk8IMKslWOuxKQ1Dp/zL8tniHSwGpRR4
VxGIX4Tmh1V8T8iBurJhJlsiltCEJxLQ1lPVYjV6Or9UJpl0B//Cl69b7rl4svo0
nz5ZOp5JHe6x9eI4oMQ8DUZH62oIHjCCk3V0CP/w0grAz1xmVdgB1Rnc8Q87O9Da
rqJwTiZcCBRoVKsLm1JADSxEa3HoWYhyHxdNaBmeTRtsA5+RRQ9hZvy1p1DQRFDW
dVUAMgUIr5snaa+oac17zvjeBMHq0AgAPU84V80U6ed69+jhSDYg+rFp7nfYwEQE
tpeunyxnah5FfMyBLj/omRviFm5LtTEw6wqBDxLAGK2H4bXr9pyrCb3BKBMpbQeB
SeiUhOWEdGyMCoroKG8kkMSnYtci5b/PA86nPSB7MA5Zhw++tioLxdH3ipJZH6uX
Bvp30LbnkX3a3aVG4ga0ykNmETJXgQPX2EJtvrUBdnAB3Sv1MKBpDzWPUA+ZJcMe
77SCkRWKSNjRJIoiyJoj0mPSSP80+vduQtfe+5BZT8qZoaTceTc=
=stKv
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: latest situation with escaped path delimiters in URI
Posted by Garret Wilson <ga...@globalmentor.com>.
On 2/4/2019 7:31 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Garret,
>
> On 2/3/19 16:20, Garret Wilson wrote:
>> If we want to look up the thing identified by
>> https://example.info/foobar, we would need to issue a request to
>> https://example.com/https%3A%2F%2Fexample.info%2Ffoobar/description
> Why
> are you %-encoding the slashes at all? They are perfectly legal as-is.
Hmmm… So let's say my RESTful API endpoint is
https://example.com/{thingURI}/description as I mentioned. (Yes, I know
that RESTful APIs don't have to be meaningful or structured as long as
we use HATEOAS, but… a lot of us like them.) So you're saying that to
request information for the resource https://example.info/foobar, I
would send a GET request to:
https://example.com/https%3A//example.info/foobar/description
That raises all sorts of questions, such as
* The double slash is OK? Really!??
* Is there any RESTful API framework on the planet that would realize
the URI path "/https%3A//example.info/foobar/description" matched
"{thingURI}/description"? So if I'm using JAX-RS with a
@Path("{thingURI}/description") with a string @PathParam("thingURI")
thing, JAX-RS would set the "thing" parameter to
"https://example.info/foobar"?? I highly doubt that.
Either I'm missing something and I'm going to learn something cool; or
you missed some of the details of what I wrote. :) If I'm missing
something, please explain because I'm ready to learn!
Garret
Re: latest situation with escaped path delimiters in URI
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Garret,
On 2/3/19 16:20, Garret Wilson wrote:
> If we want to look up the thing identified by
> https://example.info/foobar, we would need to issue a request to
> https://example.com/https%3A%2F%2Fexample.info%2Ffoobar/description
Why
>
are you %-encoding the slashes at all? They are perfectly legal as-is.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxYrzkACgkQHPApP6U8
pFjPgw/+O5zgYuqymSO6wh1RMURAEdPcdB8K3phh0W6PqtYWE3IlQHNewdEJEYlW
iNXuvRerdl+L0rthDR4VYOU53yk3ckA2qIrOLsK+BQGZ+mQZFUjSmnaMdGCAmSft
qJJiHmttbzNUgT9z4hzaFYawpBoIYBN+Tb2pfACcyOHiUWzEEgKSa0lqHS+1kT3Q
hLuF9mfe+lppTuLMjlSha4gtPJNeLH3ljTWM9/sek54XjMt5SDSEpl8MY5iDHdOd
rFh2NT3KS/dcfgJtzlhR+ACR/0CpbmWqP5QJ0DVyZeKbedVZ/9i8KCDwGBBPfrjj
tyIQfmtWNusZb7JxaUFcyIO4Am8h+yShbHSmhSaDHS9S8tbVRl1x++9ufgxAtWwE
dUackFAY6lkASSIrN3fKeR02NMderMJw9MIu+AWS3IrZx5KAV9DxDOWBzk8pj3wR
hDeesIVLSKemZT8NPjkQe0Yyv2KejME2IO/JsrFyzoXtgfoxBjs3ghgMExu7Ybna
dkqPVvZK8RKBaE1i8CrdXfESpwIemCydGdW9y3jbKYbubf5+Q5Z8n2H14fQPltvz
iVfO3pby3X2PdhMptT2auHGU8JpF+TdtpEwERgO5ceuIdV2tT6gCDQFTmiujIK+Y
CRlBHEZg/CAOdH+oOdNrFWhWlHj8cQrFvSUc3z2CCiwxpjFnHhY=
=KcBY
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org