Bug 969547 - RewriteConds are broken and not applied
RewriteConds are broken and not applied
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web (Show other bugs)
6.1.0
Unspecified Unspecified
urgent Severity urgent
: ER1
: EAP 6.1.1
Assigned To: Aaron Ogburn
:
: 1000230 (view as bug list)
Depends On:
Blocks: 970751 974237
  Show dependency treegraph
 
Reported: 2013-05-31 14:45 EDT by Aaron Ogburn
Modified: 2013-09-16 16:25 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 974237 (view as bug list)
Environment:
Last Closed: 2013-09-16 16:25:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aaron Ogburn 2013-05-31 14:45:33 EDT
Description of problem:

RewriteConds are broken and not applied


Version-Release number of selected component (if applicable):


How reproducible:

Always


Steps to Reproduce:
1. Set a rewrite rule with a condition
2. Note that the condition has no effect


Actual results:

RewriteConds are not applied and used as specified in the standalone/domain xml


Expected results:

RewriteConds are used


Additional info:

During start up with similar rewrite conditions on 6.0.1, we get a clear indication the rule is added along with the condition:

DEBUG [org.apache.catalina.core.ContainerBase.[default-host]] (MSC service thread 1-4) Add rule with pattern ^/foo(.*)$ and substitution /bar
DEBUG [org.apache.catalina.core.ContainerBase.[default-host]] (MSC service thread 1-4) Add condition 8081 test %{SERVER_PORT} to rule with pattern ^/foo(.*)$ and substitution /bar [NC]


On 6.1.0, there is only an indication that the rule is added and nothing about the condition, suggesting the condition never makes it from the config to the actual rewrite conditions/rules built and used by JBoss.
Comment 1 Aaron Ogburn 2013-05-31 14:51:33 EDT
I debugged further with ByteMan to see what was dropping the rewrite condition.  RewriteValve clearly received no RewriteConds in its configuration string that it parses to build the rules.  I believe the following byteman rules expose the issue clearly enough:

RULE WebVirtualHostAddResolveRewriteExpressionsCondCheck
CLASS org.jboss.as.web.WebVirtualHostAdd
METHOD resolveRewriteExpressions
AT LINE 170
IF TRUE
DO traceStack("----------------------->WebVirtualHostAdd.resolveRewriteExpressions: conditioncheck\n" + $resolvedCondition + "\n");
#DO $result.get(Constants.CONDITION, conditionProp.getName()).set(resolvedCondition);
ENDRULE

RULE WebVirtualHostServiceSetRewrite
CLASS org.jboss.as.web.WebVirtualHostService
METHOD setRewrite
IF TRUE
DO traceStack("----------------------->WebVirtualHostService.setRewrite:\n" + $1 + "\n");
ENDRULE


This shows we clearly provide no condition through WebVirtualHostService.setRewrite:

10:54:20,926 INFO  [stdout] (ServerService Thread Pool -- 45) ----------------------->WebVirtualHostService.setRewrite:
10:54:20,927 INFO  [stdout] (ServerService Thread Pool -- 45) {"rule-1" => {
10:54:20,927 INFO  [stdout] (ServerService Thread Pool -- 45)     "pattern" => "^/helloworld2(.*)$",
10:54:20,927 INFO  [stdout] (ServerService Thread Pool -- 45)     "substitution" => "-",
10:54:20,927 INFO  [stdout] (ServerService Thread Pool -- 45)     "flags" => "F"
10:54:20,927 INFO  [stdout] (ServerService Thread Pool -- 45) }}
10:54:20,927 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.web.WebVirtualHostService.setRewrite(WebVirtualHostService.java:-1)
10:54:20,927 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.web.WebVirtualHostAdd.performRuntime(WebVirtualHostAdd.java:108)
10:54:20,927 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:50)
10:54:20,928 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440)
10:54:20,928 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
10:54:20,928 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
10:54:20,928 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
10:54:20,928 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:322)
10:54:20,928 INFO  [stdout] (ServerService Thread Pool -- 45) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
10:54:20,928 INFO  [stdout] (ServerService Thread Pool -- 45) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
10:54:20,928 INFO  [stdout] (ServerService Thread Pool -- 45) java.lang.Thread.run(Thread.java:636)
10:54:20,928 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.threads.JBossThread.run(JBossThread.java:122)


The other rule shows that that at line 170 we clearly have the full condition added to the resolved parent:

14:37:16,454 INFO  [stdout] (ServerService Thread Pool -- 45) ----------------------->WebVirtualHostAdd.resolveRewriteExpressions: conditioncheck
14:37:16,454 INFO  [stdout] (ServerService Thread Pool -- 45) {
14:37:16,454 INFO  [stdout] (ServerService Thread Pool -- 45)     "test" => "%{SERVER_PORT}",
14:37:16,454 INFO  [stdout] (ServerService Thread Pool -- 45)     "pattern" => "!8081",
14:37:16,454 INFO  [stdout] (ServerService Thread Pool -- 45)     "flags" => "NC"
14:37:16,454 INFO  [stdout] (ServerService Thread Pool -- 45) }
14:37:16,455 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.web.WebVirtualHostAdd.resolveRewriteExpressions(WebVirtualHostAdd.java:170)
14:37:16,455 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.web.WebVirtualHostAdd.performRuntime(WebVirtualHostAdd.java:107)
14:37:16,455 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:50)
14:37:16,455 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440)
14:37:16,455 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
14:37:16,456 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
14:37:16,456 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
14:37:16,456 INFO  [stdout] (ServerService Thread Pool -- 45) org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:322)
14:37:16,456 INFO  [stdout] (ServerService Thread Pool -- 45) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
14:37:16,456 INFO  [stdout] (ServerService Thread Pool -- 45) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
14:37:16,456 INFO  [stdout] (ServerService Thread Pool -- 45) java.lang.Thread.run(Thread.java:636)
Comment 2 Aaron Ogburn 2013-05-31 14:52:28 EDT
Looks like the problem is line 170 of WebVirtualHostService.resolveRewriteExpressions:

162     private ModelNode resolveRewriteExpressions(OperationContext context, ModelNode unresolvedRewriteChildren) throws OperationFailedException {
163         ModelNode result = new ModelNode();
164         for (Property prop : unresolvedRewriteChildren.asPropertyList()) {
165             ModelNode resolvedParent = resolveExpressions(context, prop.getValue(), WebReWriteDefinition.ATTRIBUTES);
166             result.get(prop.getName()).set(resolvedParent);
167             if (prop.getValue().hasDefined(Constants.CONDITION)) {
168                 for (Property conditionProp : prop.getValue().get(Constants.CONDITION).asPropertyList()) {
169                     ModelNode resolvedCondition = resolveExpressions(context, conditionProp.getValue(), WebReWriteConditionDefinition.ATTRIBUTES);
170                     resolvedParent.get(Constants.CONDITION, conditionProp.getName()).set(resolvedCondition);
171                 }
172             }
173         } 
174         return result;
175     }


result.get(prop.getName()).set means we copy the value of resolvedParent.  We're not using the same object as resolvedParent, we're using a copy of it, and so setting the resolvedCondition on resolvedParent isn't returned in the result ModelNode that we've built.  Looks like a simple change, applying the resolved condition to the rewrite prop in the result node, would do the trick: 

    result.get(prop.getName()).get(Constants.CONDITION, conditionProp.getName()).set(resolvedCondition);


Thoughts?
Comment 3 Aaron Ogburn 2013-05-31 15:18:18 EDT
WebVirtualHostAdd.resolveRewriteExpressions() being the problem method rather.
Comment 4 Aaron Ogburn 2013-06-03 09:16:59 EDT
Upstream bug:

https://issues.jboss.org/browse/WFLY-1282
Comment 8 Petr Kremensky 2013-06-19 04:31:51 EDT
Verified on EAP 6.1.1 ER1
Comment 9 Hisanobu Okuda 2013-08-23 03:35:24 EDT
*** Bug 1000230 has been marked as a duplicate of this bug. ***
Comment 10 Scott Mumford 2013-08-28 23:56:22 EDT
Marking for exclusion from the 6.1.1 Release Notes document as an entry for this bug could not be completed or verified in time.

Note You need to log in before you can comment on or make changes to this bug.