You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Bertrand Delacretaz (JIRA)" <ji...@apache.org> on 2007/11/30 15:51:43 UTC
[jira] Created: (SLING-117) MicroslingResourceResolver should not
go up the path hierarchy for GET requests
MicroslingResourceResolver should not go up the path hierarchy for GET requests
-------------------------------------------------------------------------------
Key: SLING-117
URL: https://issues.apache.org/jira/browse/SLING-117
Project: Sling
Issue Type: Improvement
Components: microsling
Reporter: Bertrand Delacretaz
Priority: Minor
Currently, resolving a request to /content/foo/bar finds the /content/foo Resource if it exists and if /content/foo/bar doesn't.
This is needed for POST requests that need to create content under non-existing paths, but for GET this leads to duplicate URLs which point to the same Resource.
This can be confusing and cause search engines to downgrade site rankings, due to redundant URLs.
I'll discuss this on list, but I'm creating this issue to make sure we handle this problem sooner or later.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-117) MicroslingResourceResolver should not
go up the path hierarchy for GET requests
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550183 ]
Bertrand Delacretaz commented on SLING-117:
-------------------------------------------
I have removed the above DefaultSlingServlet workaround in revision 603045
> MicroslingResourceResolver should not go up the path hierarchy for GET requests
> -------------------------------------------------------------------------------
>
> Key: SLING-117
> URL: https://issues.apache.org/jira/browse/SLING-117
> Project: Sling
> Issue Type: Improvement
> Components: microsling
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: SLING-117.GetWithSuffixTest.patch
>
>
> Currently, resolving a request to /content/foo/bar finds the /content/foo Resource if it exists and if /content/foo/bar doesn't.
> This is needed for POST requests that need to create content under non-existing paths, but for GET this leads to duplicate URLs which point to the same Resource.
> This can be confusing and cause search engines to downgrade site rankings, due to redundant URLs.
> I'll discuss this on list, but I'm creating this issue to make sure we handle this problem sooner or later.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-117) MicroslingResourceResolver should not
go up the path hierarchy for GET requests
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bertrand Delacretaz updated SLING-117:
--------------------------------------
Attachment: SLING-117.GetWithSuffixTest.patch
GetWithSuffixTest, currently fails as requesting a resource with an extra suffix at the end of the path works in some cases.
The DefaultSlingServlet currently the workaround shown below to block this for default renderings:
if(suffix != null && suffix.length() > 0) {
// accept exact addressing only for default rendering:
// a non-empty suffix means there was extra stuff after the path
// of the resource
throw new HttpStatusCodeException(
HttpServletResponse.SC_NOT_FOUND,
"Ancestor resource found (" + r.getResourceMetadata().get(ResourceMetadata.RESOLUTION_PATH) + ")"
+ " but URL suffix must be empty for default rendering (suffix=" + suffix + ")"
);
}
But this is not sufficient (testWithExtraPathB fails in the attached patch), and done in the wrong place as it only applies to default rendering.
> MicroslingResourceResolver should not go up the path hierarchy for GET requests
> -------------------------------------------------------------------------------
>
> Key: SLING-117
> URL: https://issues.apache.org/jira/browse/SLING-117
> Project: Sling
> Issue Type: Improvement
> Components: microsling
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: SLING-117.GetWithSuffixTest.patch
>
>
> Currently, resolving a request to /content/foo/bar finds the /content/foo Resource if it exists and if /content/foo/bar doesn't.
> This is needed for POST requests that need to create content under non-existing paths, but for GET this leads to duplicate URLs which point to the same Resource.
> This can be confusing and cause search engines to downgrade site rankings, due to redundant URLs.
> I'll discuss this on list, but I'm creating this issue to make sure we handle this problem sooner or later.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SLING-117) MicroslingResourceResolver
should not go up the path hierarchy for GET requests
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547170 ]
bdelacretaz edited comment on SLING-117 at 11/30/07 7:05 AM:
---------------------------------------------------------------------
The attached patch contains GetWithSuffixTest, currently fails as requesting a resource with an extra suffix at the end of the path works in some cases.
The DefaultSlingServlet currently the workaround shown below to block this for default renderings:
if(suffix != null && suffix.length() > 0) {
// accept exact addressing only for default rendering:
// a non-empty suffix means there was extra stuff after the path
// of the resource
throw new HttpStatusCodeException(
HttpServletResponse.SC_NOT_FOUND,
"Ancestor resource found (" + r.getResourceMetadata().get(ResourceMetadata.RESOLUTION_PATH) + ")"
+ " but URL suffix must be empty for default rendering (suffix=" + suffix + ")"
);
}
But this is not sufficient (testWithExtraPathB fails in the attached patch), and done in the wrong place as it only applies to default rendering.
was (Author: bdelacretaz):
GetWithSuffixTest, currently fails as requesting a resource with an extra suffix at the end of the path works in some cases.
The DefaultSlingServlet currently the workaround shown below to block this for default renderings:
if(suffix != null && suffix.length() > 0) {
// accept exact addressing only for default rendering:
// a non-empty suffix means there was extra stuff after the path
// of the resource
throw new HttpStatusCodeException(
HttpServletResponse.SC_NOT_FOUND,
"Ancestor resource found (" + r.getResourceMetadata().get(ResourceMetadata.RESOLUTION_PATH) + ")"
+ " but URL suffix must be empty for default rendering (suffix=" + suffix + ")"
);
}
But this is not sufficient (testWithExtraPathB fails in the attached patch), and done in the wrong place as it only applies to default rendering.
> MicroslingResourceResolver should not go up the path hierarchy for GET requests
> -------------------------------------------------------------------------------
>
> Key: SLING-117
> URL: https://issues.apache.org/jira/browse/SLING-117
> Project: Sling
> Issue Type: Improvement
> Components: microsling
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: SLING-117.GetWithSuffixTest.patch
>
>
> Currently, resolving a request to /content/foo/bar finds the /content/foo Resource if it exists and if /content/foo/bar doesn't.
> This is needed for POST requests that need to create content under non-existing paths, but for GET this leads to duplicate URLs which point to the same Resource.
> This can be confusing and cause search engines to downgrade site rankings, due to redundant URLs.
> I'll discuss this on list, but I'm creating this issue to make sure we handle this problem sooner or later.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SLING-117) MicroslingResourceResolver
should not go up the path hierarchy for GET requests
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547170 ]
bdelacretaz edited comment on SLING-117 at 11/30/07 7:06 AM:
---------------------------------------------------------------------
The attached patch contains GetWithSuffixTest, currently fails as requesting a resource with an extra suffix at the end of the path works in some cases.
The DefaultSlingServlet currently uses the workaround shown below to block this for default renderings:
if(suffix != null && suffix.length() > 0) {
// accept exact addressing only for default rendering:
// a non-empty suffix means there was extra stuff after the path
// of the resource
throw new HttpStatusCodeException(
HttpServletResponse.SC_NOT_FOUND,
"Ancestor resource found (" + r.getResourceMetadata().get(ResourceMetadata.RESOLUTION_PATH) + ")"
+ " but URL suffix must be empty for default rendering (suffix=" + suffix + ")"
);
}
But this is not sufficient (testWithExtraPathB fails in the attached patch), and done in the wrong place as it only applies to default rendering.
was (Author: bdelacretaz):
The attached patch contains GetWithSuffixTest, currently fails as requesting a resource with an extra suffix at the end of the path works in some cases.
The DefaultSlingServlet currently the workaround shown below to block this for default renderings:
if(suffix != null && suffix.length() > 0) {
// accept exact addressing only for default rendering:
// a non-empty suffix means there was extra stuff after the path
// of the resource
throw new HttpStatusCodeException(
HttpServletResponse.SC_NOT_FOUND,
"Ancestor resource found (" + r.getResourceMetadata().get(ResourceMetadata.RESOLUTION_PATH) + ")"
+ " but URL suffix must be empty for default rendering (suffix=" + suffix + ")"
);
}
But this is not sufficient (testWithExtraPathB fails in the attached patch), and done in the wrong place as it only applies to default rendering.
> MicroslingResourceResolver should not go up the path hierarchy for GET requests
> -------------------------------------------------------------------------------
>
> Key: SLING-117
> URL: https://issues.apache.org/jira/browse/SLING-117
> Project: Sling
> Issue Type: Improvement
> Components: microsling
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: SLING-117.GetWithSuffixTest.patch
>
>
> Currently, resolving a request to /content/foo/bar finds the /content/foo Resource if it exists and if /content/foo/bar doesn't.
> This is needed for POST requests that need to create content under non-existing paths, but for GET this leads to duplicate URLs which point to the same Resource.
> This can be confusing and cause search engines to downgrade site rankings, due to redundant URLs.
> I'll discuss this on list, but I'm creating this issue to make sure we handle this problem sooner or later.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-117) MicroslingResourceResolver should not
go up the path hierarchy for GET requests
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550181 ]
Bertrand Delacretaz commented on SLING-117:
-------------------------------------------
In revision 603042, I have modified ResourcePathIterator so that the resource resolution does not go up the path anymore for GET or HEAD requests.
This will probably need some refinements, as is being discussed on the sling dev list.
> MicroslingResourceResolver should not go up the path hierarchy for GET requests
> -------------------------------------------------------------------------------
>
> Key: SLING-117
> URL: https://issues.apache.org/jira/browse/SLING-117
> Project: Sling
> Issue Type: Improvement
> Components: microsling
> Reporter: Bertrand Delacretaz
> Priority: Minor
> Attachments: SLING-117.GetWithSuffixTest.patch
>
>
> Currently, resolving a request to /content/foo/bar finds the /content/foo Resource if it exists and if /content/foo/bar doesn't.
> This is needed for POST requests that need to create content under non-existing paths, but for GET this leads to duplicate URLs which point to the same Resource.
> This can be confusing and cause search engines to downgrade site rankings, due to redundant URLs.
> I'll discuss this on list, but I'm creating this issue to make sure we handle this problem sooner or later.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-117) MicroslingResourceResolver should not go
up the path hierarchy for GET requests
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger closed SLING-117.
-----------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0
Assignee: Bertrand Delacretaz
Fixed in both microsling and the real sling: Regardless of the request method, the URL is now always only cut at dots starting from the end to find a matching resource.
> MicroslingResourceResolver should not go up the path hierarchy for GET requests
> -------------------------------------------------------------------------------
>
> Key: SLING-117
> URL: https://issues.apache.org/jira/browse/SLING-117
> Project: Sling
> Issue Type: Improvement
> Components: microsling
> Reporter: Bertrand Delacretaz
> Assignee: Bertrand Delacretaz
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: SLING-117.GetWithSuffixTest.patch
>
>
> Currently, resolving a request to /content/foo/bar finds the /content/foo Resource if it exists and if /content/foo/bar doesn't.
> This is needed for POST requests that need to create content under non-existing paths, but for GET this leads to duplicate URLs which point to the same Resource.
> This can be confusing and cause search engines to downgrade site rankings, due to redundant URLs.
> I'll discuss this on list, but I'm creating this issue to make sure we handle this problem sooner or later.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.