On 06/02/2020 23:00, Mark Thomas wrote:
> The issue appears to be that the following RewriteCond does not match
> when the request is served over HTTP/2 (with TLS) but it does if the
> request is served over HTTP/1.1 with TLS.
>
> RewriteCond %{HTTP_HOST} localhost
>
> (Note the RewriteCond quoted at the start of this thread is invalid)
>
> I'm wondering if this is related to the thread about
> HttpServletRequest.getRemoteAddr() returning null at the start of a
> request. It looks as if the request information may be being populated
> too late.
Nope. Unrelated.
The root cause here is that the RewriteCond is looking for an HTTP Host
header but HTTP/2 does not have any such header.
HTTP/2 has the pseudo-header ":authority" that replaces the Host header.
While you could argue that a strict interpretation of the mod_rewrite
docs (since the rewrite valve aims to emulate a sub-set of mod_rewrite
behaviour) means that "host" != ":authority" I think the reasonable
thing to do in this instance is to look at the ":authority" value if the
request is using HTTP/2. I'll work on a patch.
Mark
>
> Mark
>
>
>
> On 06/02/2020 20:42, Pierre Chiu wrote:
>> I just want to concur I have the same issue.
>> Removing that one line upgradeprotocol
>> and rewrite works again.
>>
>>
>>
>> On Thu, Feb 6, 2020 at 3:28 PM Hua Zhang <hzhang1...@gmail.com> wrote:
>>
>>> Nope, I also tested it with NIO instead of APR, same issues happen.
>>> RewriteValve does not function as expected. Besides it, there are also two
>>> https-443-exec executed by one request.
>>>
>>> There is definitely something wrong with Http2Protocol. And it results in
>>> this case a problem in RewriteValve.
>>>
>>> And what kind of extra information do you want to have. I cannot send any
>>> pictures in the email. You want the server.xml configuration? Except that
>>> file, almost every other configuration file is untouched. No load balancer,
>>> no any proxy here. Just a straight forward connection to tomcat instance.
>>>
>>> Here an remark, you can only reproduce errors if Http2Protocol is indeed
>>> activated, namely you see in browser h2 protocol is used by request. In
>>> Eclipse, I cannot reproduce the issue, since I cannot get h2 protocol
>>> working there.
>>>
>>>
>>> Hua
>>>
>>> Rémy Maucherat <r...@apache.org> 于 2020年2月6日周四 下午3:06写道：
>>>
>>>> On Thu, Feb 6, 2020 at 2:56 PM Hua Zhang <hzhang1...@gmail.com> wrote:
>>>>
>>>>> Thank you for the response. I am finally able to confirm the issue.
>>>>>
>>>>> When I put the following line in comment, everything works fine. I mean
>>>> as
>>>>> expected.
>>>>>
>>>>> *<!-- <UpgradeProtocol
>>> className="org.apache.coyote.http2.Http2Protocol"
>>>> />
>>>>> -->*
>>>>>
>>>>>
>>>>> If the above line UpgradeProtocol is activated, I observe now at least
>>>> two
>>>>> weird situations.
>>>>>
>>>>> 1) As mentioned before, RewriteValve does not work as expected.
>>>>> 2) Besides it, I observed that serviet behaviors weird. According to
>>> the
>>>>> log file it seems that a servlet is sometimes called *twice by one
>>>>> request*.
>>>>>
>>>>> This is a snapshot of my log files. You can see that two https-443-exec
>>>> are
>>>>> called almost at the same time.
>>>>>
>>>>> 06-Feb-2020 13:38:04.676 SEVERE *[https-openssl-apr-443-exec-9]*
>>>>> org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service()
>>>>> for servlet [uploadServlet] in context with path [] threw exception
>>>>>
>>>>> org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
>>>>> Stream ended unexpectedly
>>>>> 06-Feb-2020 13:38:04.999 SEVERE *[https-openssl-apr-443-exec-2]*
>>>>> org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service()
>>>>> for servlet [uploadServlet] in context with path [] threw exception
>>>>>
>>>>> org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
>>>>> Stream ended unexpectedly
>>>>>
>>>>
>>>> Ok, so your problem seems to be about HTTP/2 rather than the rewrite
>>> valve:
>>>> HTTP/2 is usually not used without TLS and ALPN. You should continue to
>>>> post more details. Something you can try is use the NIO connector (with
>>>> OpenSSL or JSSE) rather than APR, it would be a more common
>>> configuration.
>>>>
>>>> Rémy
>>>>
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Hua
>>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
