Re: AJP Protocol enhancements

[Rémy Maucherat]

2015-09-25 17:43 GMT+02:00 Andrew Carr :

> Mark,
>
> Couple of questions.  What wiki is the "new" cwiki?  Will my wiki account
> from the old server be transferred to the new cwiki?
>
> Devs,
>
> I see arguments for and against the protocol upgrade.  Based on different
> opinions, so far, we are inadvertently building a list of options for the
> future of the AJP protocol, should we consolidate these options and put it
> to a vote?  Should I just write the protocol upgrade definition (or let it
> die peacefully as jean-frederic suggested).  Something else?
>
> You can work on an AJP.next even if some are skeptical, there's no vote
needed at this stage.

Rémy

[Bug 58433] RemoteIpValve not activated on redirect from mapping

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58433

George Stanchev  changed:

   What|Removed |Added

 CC||stanc...@hotmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: AJP Protocol enhancements

[Andrew Carr]

Rémy,

Thank you.

I reread what I asked about the wiki and I realize it might not have been
clear.  Mark said,
 *"Long term, we probably do need to migrate the wiki. Short term we
can **use the new instance just for this."  *
and I was curious about access, is it already out there and I just don't
know about it, etc... the "new instance."

-Andrew




On Fri, Sep 25, 2015 at 10:01 AM, Rémy Maucherat  wrote:

> 2015-09-25 17:43 GMT+02:00 Andrew Carr :
>
> > Mark,
> >
> > Couple of questions.  What wiki is the "new" cwiki?  Will my wiki account
> > from the old server be transferred to the new cwiki?
> >
> > Devs,
> >
> > I see arguments for and against the protocol upgrade.  Based on different
> > opinions, so far, we are inadvertently building a list of options for the
> > future of the AJP protocol, should we consolidate these options and put
> it
> > to a vote?  Should I just write the protocol upgrade definition (or let
> it
> > die peacefully as jean-frederic suggested).  Something else?
> >
> > You can work on an AJP.next even if some are skeptical, there's no vote
> needed at this stage.
>
> Rémy
>



-- 
With Regards,
Andrew Carr

e. andrewlanec...@gmail.com
w. andrew.c...@openlogic.com
h. 4235255668
c. 4239489852
a. P.O. Box 1231, Greeneville, TN, 37744

Re: AJP Protocol enhancements

[Andrew Carr]

Mark,

Couple of questions.  What wiki is the "new" cwiki?  Will my wiki account
from the old server be transferred to the new cwiki?

Devs,

I see arguments for and against the protocol upgrade.  Based on different
opinions, so far, we are inadvertently building a list of options for the
future of the AJP protocol, should we consolidate these options and put it
to a vote?  Should I just write the protocol upgrade definition (or let it
die peacefully as jean-frederic suggested).  Something else?

-Andrew

svn commit: r1705349 - in /tomcat/trunk/java/org/apache/coyote: AbstractProcessor.java ActionCode.java http2/AbstractStream.java http2/Http2UpgradeHandler.java http2/LocalStrings.properties http2/Stre

[markt]

Author: markt
Date: Fri Sep 25 20:29:30 2015
New Revision: 1705349

URL: http://svn.apache.org/viewvc?rev=1705349=rev
Log:
More work on servlet 3.1 non-blocking for HTTP/2. NumberWriter works.

Modified:
tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java
tomcat/trunk/java/org/apache/coyote/ActionCode.java
tomcat/trunk/java/org/apache/coyote/http2/AbstractStream.java
tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java
tomcat/trunk/java/org/apache/coyote/http2/LocalStrings.properties
tomcat/trunk/java/org/apache/coyote/http2/Stream.java
tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java

Modified: tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java?rev=1705349=1705348=1705349=diff
==
--- tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java Fri Sep 25 
20:29:30 2015
@@ -78,7 +78,8 @@ public abstract class AbstractProcessor
 }
 
 
-private AbstractProcessor(AbstractEndpoint endpoint, Request 
coyoteRequest, Response coyoteResponse) {
+private AbstractProcessor(AbstractEndpoint endpoint, Request 
coyoteRequest,
+Response coyoteResponse) {
 this.endpoint = endpoint;
 asyncStateMachine = new AsyncStateMachine(this);
 request = coyoteRequest;

Modified: tomcat/trunk/java/org/apache/coyote/ActionCode.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/ActionCode.java?rev=1705349=1705348=1705349=diff
==
--- tomcat/trunk/java/org/apache/coyote/ActionCode.java (original)
+++ tomcat/trunk/java/org/apache/coyote/ActionCode.java Fri Sep 25 20:29:30 2015
@@ -195,13 +195,15 @@ public enum ActionCode {
 
 /**
  * Indicator that Servlet is interested in being
- * notified when data is available to be read
+ * notified when data is available to be read.
  */
 NB_READ_INTEREST,
 
 /**
- *Indicator that the Servlet is interested
- *in being notified when it can write data
+ * Used with non-blocking writes to determine if a write is currently
+ * allowed (sets passed parameter to true) or not (sets passed
+ * parameter to false). If a write is not allowed then 
callback
+ * will be triggered at some future point when write becomes possible 
again.
  */
 NB_WRITE_INTEREST,
 

Modified: tomcat/trunk/java/org/apache/coyote/http2/AbstractStream.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/AbstractStream.java?rev=1705349=1705348=1705349=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/AbstractStream.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/AbstractStream.java Fri Sep 25 
20:29:30 2015
@@ -147,4 +147,6 @@ abstract class AbstractStream {
 protected abstract String getConnectionId();
 
 protected abstract int getWeight();
+
+protected abstract void doNotifyAll();
 }

Modified: tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java?rev=1705349=1705348=1705349=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
(original)
+++ tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java Fri Sep 
25 20:29:30 2015
@@ -638,7 +638,7 @@ public class Http2UpgradeHandler extends
 if (allocation > 0) {
 backLogSize -= allocation;
 synchronized (entry.getKey()) {
-entry.getKey().notifyAll();
+entry.getKey().doNotifyAll();
 }
 }
 }
@@ -646,6 +646,13 @@ public class Http2UpgradeHandler extends
 }
 
 
+
+@Override
+protected synchronized void doNotifyAll() {
+this.notifyAll();
+}
+
+
 private int allocate(AbstractStream stream, int allocation) {
 if (log.isDebugEnabled()) {
 log.debug(sm.getString("upgradeHandler.allocate.debug", 
getConnectionId(),

Modified: tomcat/trunk/java/org/apache/coyote/http2/LocalStrings.properties
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/LocalStrings.properties?rev=1705349=1705348=1705349=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/LocalStrings.properties (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/LocalStrings.properties Fri Sep 
25 20:29:30 2015
@@ -72,7 +72,10 @@ stream.write=Connection [{0}], Stream [{
 
 

svn commit: r1705353 - in /tomcat/trunk/java/org/apache/coyote/http2: Stream.java StreamProcessor.java

[markt]

Author: markt
Date: Fri Sep 25 21:05:53 2015
New Revision: 1705353

URL: http://svn.apache.org/viewvc?rev=1705353=rev
Log:
Start thinking about non-blocking reads

Modified:
tomcat/trunk/java/org/apache/coyote/http2/Stream.java
tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java

Modified: tomcat/trunk/java/org/apache/coyote/http2/Stream.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/Stream.java?rev=1705353=1705352=1705353=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/Stream.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/Stream.java Fri Sep 25 21:05:53 
2015
@@ -292,6 +292,11 @@ public class Stream extends AbstractStre
 }
 
 
+StreamInputBuffer getInputBuffer() {
+return inputBuffer;
+}
+
+
 StreamOutputBuffer getOutputBuffer() {
 return outputBuffer;
 }
@@ -473,6 +478,7 @@ public class Stream extends AbstractStre
 // This buffer is the destination for incoming data. It is normally is
 // 'write mode'.
 private volatile ByteBuffer inBuffer;
+private volatile boolean readInterest;
 
 @Override
 public int doRead(ByteChunk chunk) throws IOException {
@@ -519,6 +525,28 @@ public class Stream extends AbstractStre
 }
 
 
+boolean isReady() {
+synchronized (inBuffer) {
+if (inBuffer.position() == 0) {
+readInterest = true;
+return false;
+} else {
+return true;
+}
+}
+}
+
+
+synchronized boolean isRegisteredForRead() {
+if (readInterest) {
+readInterest = false;
+return true;
+} else {
+return false;
+}
+}
+
+
 public ByteBuffer getInBuffer() {
 ensureBuffersExist();
 return inBuffer;
@@ -526,13 +554,12 @@ public class Stream extends AbstractStre
 
 
 private void ensureBuffersExist() {
-if (inBuffer != null) {
-return;
-}
-synchronized (this) {
-if (inBuffer == null) {
-inBuffer = ByteBuffer.allocate(16 * 1024);
-outBuffer = new byte[16 * 1024];
+if (inBuffer == null) {
+synchronized (this) {
+if (inBuffer == null) {
+inBuffer = ByteBuffer.allocate(16 * 1024);
+outBuffer = new byte[16 * 1024];
+}
 }
 }
 }

Modified: tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java?rev=1705353=1705352=1705353=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java Fri Sep 25 
21:05:53 2015
@@ -298,6 +298,11 @@ public class StreamProcessor extends Abs
 result.set(stream.isInputFinished());
 break;
 }
+case NB_READ_INTEREST: {
+AtomicBoolean result = (AtomicBoolean) param;
+result.set(stream.getInputBuffer().isReady());
+break;
+}
 case NB_WRITE_INTEREST: {
 AtomicBoolean result = (AtomicBoolean) param;
 result.set(stream.getOutputBuffer().isReady());
@@ -327,7 +332,6 @@ public class StreamProcessor extends Abs
 case CLOSE_NOW:
 case DISABLE_SWALLOW_INPUT:
 case END_REQUEST:
-case NB_READ_INTEREST:
 case REQ_SET_BODY_REPLAY:
 case RESET:
 log.info("TODO: Implement [" + actionCode + "] for HTTP/2");



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 58458] Change in Expect100Continue behaviour in Tomcat is breaking existing clients with HTTP 40x results

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58458

--- Comment #2 from Oliver  ---
Created attachment 33148
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=33148=edit
testcase with curl on windows

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1705350 - /tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java

[markt]

Author: markt
Date: Fri Sep 25 20:48:14 2015
New Revision: 1705350

URL: http://svn.apache.org/viewvc?rev=1705350=rev
Log:
Fixed this TODO before last commit

Modified:
tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java

Modified: tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java?rev=1705350=1705349=1705350=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java Fri Sep 25 
20:48:14 2015
@@ -299,7 +299,6 @@ public class StreamProcessor extends Abs
 break;
 }
 case NB_WRITE_INTEREST: {
-// TODO: Thread safe? Do this in output buffer?
 AtomicBoolean result = (AtomicBoolean) param;
 result.set(stream.getOutputBuffer().isReady());
 break;



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 58458] Change in Expect100Continue behaviour in Tomcat is breaking existing clients with HTTP 40x results

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58458

--- Comment #3 from Oliver  ---
Thanks for your fast response.

With curl on windows the problem is also reproducible (tomcat 7.0.64 apr and
8.0.26 apr). There is an additional testcase (batch file).

Error message:
D:\curl-7.43.0-win64\bin>TomcatExpectTest_curl.cmd
Request http://localhost:8080/myURI1
...
Request http://localhost:8080/myURI11
curl: (56) Recv failure: Connection was reset
Request http://localhost:8080/myURI12
...
Request http://localhost:8080/myURI23
curl: (56) Recv failure: Connection was reset
Request http://localhost:8080/myURI24
...
Request http://localhost:8080/myURI32
curl: (56) Recv failure: Connection was reset
Request http://localhost:8080/myURI33
curl: (56) Recv failure: Connection was reset
Request http://localhost:8080/myURI34

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1705358 - in /tomcat/trunk: java/org/apache/coyote/http2/ test/org/apache/coyote/http2/

[markt]

Author: markt
Date: Fri Sep 25 21:47:56 2015
New Revision: 1705358

URL: http://svn.apache.org/viewvc?rev=1705358=rev
Log:
Complete Servlet 3.1 non-blocking support

Modified:
tomcat/trunk/java/org/apache/coyote/http2/Http2Parser.java
tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java
tomcat/trunk/java/org/apache/coyote/http2/Stream.java
tomcat/trunk/java/org/apache/coyote/http2/StreamProcessor.java
tomcat/trunk/test/org/apache/coyote/http2/Http2TestBase.java

Modified: tomcat/trunk/java/org/apache/coyote/http2/Http2Parser.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/Http2Parser.java?rev=1705358=1705357=1705358=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/Http2Parser.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/Http2Parser.java Fri Sep 25 
21:47:56 2015
@@ -163,7 +163,7 @@ class Http2Parser {
 Integer.toString(streamId), Integer.toString(dataLength), 
padding));
 }
 
-ByteBuffer dest = output.getInputByteBuffer(streamId, dataLength);
+ByteBuffer dest = output.startRequestBodyFrame(streamId, payloadSize);
 if (dest == null) {
 swallow(streamId, dataLength, false);
 // Process padding before sending any notifications in case padding
@@ -185,7 +185,7 @@ class Http2Parser {
 if (endOfStream) {
 output.receiveEndOfStream(streamId);
 }
-dest.notifyAll();
+output.endRequestBodyFrame(streamId);
 }
 }
 if (padLength > 0) {
@@ -586,7 +586,8 @@ class Http2Parser {
 HpackDecoder getHpackDecoder();
 
 // Data frames
-ByteBuffer getInputByteBuffer(int streamId, int payloadSize) throws 
Http2Exception;
+ByteBuffer startRequestBodyFrame(int streamId, int payloadSize) throws 
Http2Exception;
+void endRequestBodyFrame(int streamId) throws Http2Exception;
 void receiveEndOfStream(int streamId) throws ConnectionException;
 void swallowedPadding(int streamId, int paddingLength) throws 
ConnectionException, IOException;
 

Modified: tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java?rev=1705358=1705357=1705358=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java 
(original)
+++ tomcat/trunk/java/org/apache/coyote/http2/Http2UpgradeHandler.java Fri Sep 
25 21:47:56 2015
@@ -953,13 +953,21 @@ public class Http2UpgradeHandler extends
 
 
 @Override
-public ByteBuffer getInputByteBuffer(int streamId, int payloadSize) throws 
Http2Exception {
+public ByteBuffer startRequestBodyFrame(int streamId, int payloadSize) 
throws Http2Exception {
 Stream stream = getStream(streamId, true);
 stream.checkState(FrameType.DATA);
 return stream.getInputByteBuffer();
 }
 
 
+
+@Override
+public void endRequestBodyFrame(int streamId) throws Http2Exception {
+Stream stream = getStream(streamId, true);
+stream.getInputBuffer().onDataAvailable();
+}
+
+
 @Override
 public void receiveEndOfStream(int streamId) throws ConnectionException {
 Stream stream = getStream(streamId, 
connectionState.get().isNewStreamAllowed());

Modified: tomcat/trunk/java/org/apache/coyote/http2/Stream.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/Stream.java?rev=1705358=1705357=1705358=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/Stream.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/Stream.java Fri Sep 25 21:47:56 
2015
@@ -21,6 +21,7 @@ import java.nio.ByteBuffer;
 import java.util.Iterator;
 
 import org.apache.coyote.ActionCode;
+import org.apache.coyote.ContainerThreadMarker;
 import org.apache.coyote.InputBuffer;
 import org.apache.coyote.OutputBuffer;
 import org.apache.coyote.Request;
@@ -537,11 +538,31 @@ public class Stream extends AbstractStre
 }
 
 
-synchronized boolean isRegisteredForRead() {
+synchronized boolean isRequestBodyFullyRead() {
+return inBuffer.position() == 0 && isInputFinished();
+}
+
+
+synchronized int available() {
+return inBuffer.position();
+}
+
+
+/*
+ * Called after placing some data in the inBuffer.
+ */
+synchronized boolean onDataAvailable() {
 if (readInterest) {
 readInterest = false;
+coyoteRequest.action(ActionCode.DISPATCH_READ, null);
+if (!ContainerThreadMarker.isContainerThread()) {
+

[Bug 58458] New: Change in Expect100Continue behaviour in Tomcat is breaking existing clients with HTTP 40x results

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58458

Bug ID: 58458
   Summary: Change in Expect100Continue behaviour in Tomcat is
breaking existing clients with HTTP 40x results
   Product: Tomcat 7
   Version: 7.0.64
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: oliver.w...@pdv.de

Created attachment 33142
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=33142=edit
Testcase

This issue is similar to bug #57324

In the version of Tomcat 7.0.50, the behavior of Coyote handler is modified to
handle "Expect: 100-continue" clients.

We use .net http clients to run multiple web service equests. The uri is
protected with spring security (kerberos / spnego) and uses requests to post
xml files and attachements to the server. Starting with tomcat 7.0.50 about 1%
to 10% of the requests fail with connection reset errors.

The problem is reproducable with a small powershell script that do 1 small
post requests with the header "Expect: 100-continue" with an uri that does not
exists in tomcat (no webapp). The expected result are 1 http 404 errors.
The problem is not reproducable when the header "Expect: 100-continue" is not
used.
The problem is not reproducable with tomcat versions 7.0.42.

No error is logged at tomcat level. The access log shows http 404 when a
request fails, but the response is not recognized by the client.


error message:
"The underlying connection was closed: An unexpected error occurred on a
receive."

additional infos:
1) .NET defaults to Expect 100 behaviour
2) .NET clients optimize the keepalive connections and do not send credentials
with every request going out on keepalive connections

Reproducable with:
7.0.64 APR Windows
7.0.64 BIO Windows
8.0.26 NIO Windows
8.0.26 APR Windows
8.0.26 NIO Linux
8.0.26 NIO2 Linux 
8.0.26 APR Windows
8.0.26 NIO2Windows
7.0.63 APR Windows
7.0.57 APR Windows
7.0.57 BIO Windows
7.0.50 APR Windows

Not reproducable with:
7.0.47 APR Windows
7.0.42 APR Windows
7.0.57 APR Linux   !
8.0.26 BIO Windows !

Windows = Windows 7 with Oracle Server JRE 8 Update 51
Linux = Oracle Linux 7 with java-1.8.0-openjdk-1.8.0.51-1.b16.el7_1.x86_64

possible workaround:
- setting expect100Continue to false at application or system level
-
http://blogs.msdn.com/b/fiddler/archive/2011/11/05/http-expect-continue-delays-transmitting-post-bodies-by-up-to-350-milliseconds.aspx
-
https://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.expect100continue%28v=vs.110%29.aspx

Testcase:
- running on windows 7 (.net framework required)
- start tomcat 7.0.64 on port 8080 
- cmd.exe
-  Powershell.exe -executionpolicy remotesigned -File TomcatExpectTest.ps1

Expect100Continue set to True
Querying http://localhost:8080/myUri(number)
09/25/2015 19:42:25 request 257 - Exception Message: Exception calling
"GetResponse" with "0" argument(s): "The underlying connection was closed: An
unexpected error occurred on a receive."
...
--- RESULTS
Requests   :  1
HTTP 404   :  9871
RST-Error  :  129<--
OTHER Error:  0
--- END

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 58458] Change in Expect100Continue behaviour in Tomcat is breaking existing clients with HTTP 40x results

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58458

Michael Osipov <1983-01...@gmx.net> changed:

   What|Removed |Added

 OS||All

--- Comment #1 from Michael Osipov <1983-01...@gmx.net> ---
Have you tried another client like curl? Microsoft's Expect100Continue
implementation is known be to problemeatic (crap). I have instructed all .NET
clients to disable this header.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: AJP Protocol enhancements

[Mark Thomas]

On 25/09/2015 17:05, Andrew Carr wrote:
> Rémy,
> 
> Thank you.
> 
> I reread what I asked about the wiki and I realize it might not have been
> clear.  Mark said,
>  *"Long term, we probably do need to migrate the wiki. Short term we
> can **use the new instance just for this."  *
> and I was curious about access, is it already out there and I just don't
> know about it, etc... the "new instance."

I need to get that set up. Give me 24 hours. I plan to move just the
dev/design content form the old wiki at this point. We can decide what
to do about the other content later.

You'll need to sign up for an account at cwiki.apache.org.

Mark


> 
> -Andrew
> 
> 
> 
> 
> On Fri, Sep 25, 2015 at 10:01 AM, Rémy Maucherat  wrote:
> 
>> 2015-09-25 17:43 GMT+02:00 Andrew Carr :
>>
>>> Mark,
>>>
>>> Couple of questions.  What wiki is the "new" cwiki?  Will my wiki account
>>> from the old server be transferred to the new cwiki?
>>>
>>> Devs,
>>>
>>> I see arguments for and against the protocol upgrade.  Based on different
>>> opinions, so far, we are inadvertently building a list of options for the
>>> future of the AJP protocol, should we consolidate these options and put
>> it
>>> to a vote?  Should I just write the protocol upgrade definition (or let
>> it
>>> die peacefully as jean-frederic suggested).  Something else?
>>>
>>> You can work on an AJP.next even if some are skeptical, there's no vote
>> needed at this stage.
>>
>> Rémy
>>
> 
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: AJP Protocol enhancements

[Mark Thomas]

On 25/09/2015 18:38, Mark Thomas wrote:
> On 25/09/2015 17:05, Andrew Carr wrote:
>> Rémy,
>>
>> Thank you.
>>
>> I reread what I asked about the wiki and I realize it might not have been
>> clear.  Mark said,
>>  *"Long term, we probably do need to migrate the wiki. Short term we
>> can **use the new instance just for this."  *
>> and I was curious about access, is it already out there and I just don't
>> know about it, etc... the "new instance."
> 
> I need to get that set up. Give me 24 hours. I plan to move just the
> dev/design content form the old wiki at this point. We can decide what
> to do about the other content later.
> 
> You'll need to sign up for an account at cwiki.apache.org.

https://cwiki.apache.org/confluence/display/TOMCAT/Apache+Tomcat+Home

I haven't moved the other dev/design content yet. I'll do that soon.

Mark


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GUMP@vmgump]: Project tomcat-tc7.0.x-test-nio (in module tomcat-7.0.x) failed

[Bill Barker]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project tomcat-tc7.0.x-test-nio has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-tc7.0.x-test-nio :  Tomcat 7.x, a web server implementing Java 
Servlet 3.0,
...


Full details are available at:

http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test-nio/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on tomcat-tc7.0.x-dbcp exists, no need to add for property 
tomcat-dbcp-src.jar.
 -DEBUG- Dependency on commons-daemon exists, no need to add for property 
commons-daemon.native.src.tgz.
 -DEBUG- Dependency on commons-daemon exists, no need to add for property 
tomcat-native.tar.gz.
 -DEBUG- Dependency on tomcat-tc7.0.x-dbcp exists, no need to add for property 
tomcat-dbcp.home.
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: 
/srv/gump/public/workspace/tomcat-7.0.x/output/logs-NIO
 -INFO- Project Reports in: 
/srv/gump/public/workspace/tomcat-7.0.x/output/test-tmp-NIO/logs



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test-nio/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-test-nio.html
Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-test-nio (Type: Build)
Work ended in a state of : Failed
Elapsed: 30 mins 39 secs
Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only org.apache.tools.ant.Main 
-Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Djunit.jar=/srv/gump/public/workspace/junit/target/junit-4.13-SNAPSHOT.jar 
-Dcommons-daemon.native.src.tgz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20150925-native-src.tar.gz
 -Dtest.reports=output/logs-NIO 
-Dtomcat-native.tar.gz=/srv/gump/public/workspace/apache-commons/daemon/dist/bin/commons-daemon-20150925-native-src.tar.gz
 -Dexamples.sources.skip=true 
-Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps 
-Djdt.jar=/srv/gump/packages/eclipse/plugins/R-4.5-201506032000/ecj-4.5.jar 
-Dcommons-daemon.jar=/srv/gump/public/workspace/apache-commons/daemon/dist/commons-daemon-20150925.jar
 
-Dtomcat-dbcp-src.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-src.jar
 -Dtest.excludePerformance=true -Dtest.accesslog=true 
-Dcommons-pool.home=/srv/gump/pub
 lic/workspace/commons-pool-1.x 
-Dcommons-dbcp.home=/srv/gump/public/workspace/commons-dbcp-1.x 
-Dexecute.test.apr=false -Dexecute.test.bio=false -Dexecute.test.nio=true 
-Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-7.0.x/tomcat-deps/tomcat-dbcp-20150925.jar
 -Dtest.temp=output/test-tmp-NIO 
-Dhamcrest.jar=/srv/gump/packages/hamcrest/hamcrest-core-1.3.jar test 
[Working Directory: /srv/gump/public/workspace/tomcat-7.0.x]
CLASSPATH: 
/usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/webapps/examples/WEB-INF/classes:/srv/gump/public/workspace/tomcat-7.0.x/output/testclasses:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/bootstrap.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/bin/tomcat-juli.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/annotations-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/servlet-api.ja
 
r:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jsp-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/el-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ant.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-coyote.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/jasper-el.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-tribes.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/catalina-ha.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-api.jar:/srv/gump/public/workspace/tomcat-7.0.x/output/build/lib/tomcat-util.jar

[Bug 58457] After async request timeout, response is not closed + works on subsequent requests

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58457

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Mark Thomas  ---
Use org.apache.catalina.connector.RECYCLE_FACADES

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1705231 - /tomcat/trunk/test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java

[markt]

Author: markt
Date: Fri Sep 25 07:13:25 2015
New Revision: 1705231

URL: http://svn.apache.org/viewvc?rev=1705231=rev
Log:
Provide state info if tests fails (it failed on Gump but I have no idea why)

Modified:

tomcat/trunk/test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java

Modified: 
tomcat/trunk/test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java?rev=1705231=1705230=1705231=diff
==
--- 
tomcat/trunk/test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java 
(original)
+++ 
tomcat/trunk/test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java 
Fri Sep 25 07:13:25 2015
@@ -33,17 +33,19 @@ public class TestSecretKeyCredentialHand
 for (String digest : ALGORITHMS) {
 for (int saltLength = 1; saltLength < 20; saltLength++) {
 for (int iterations = 1; iterations < 1; iterations += 
1000)
-doTest(digest, saltLength, iterations);
+doTest(digest, saltLength, iterations);
 }
 }
 }
 
-private void doTest(String digest, int saltLength, int iterations) throws 
NoSuchAlgorithmException {
+private void doTest(String digest, int saltLength, int iterations)
+throws NoSuchAlgorithmException {
 SecretKeyCredentialHandler pbech = new SecretKeyCredentialHandler();
 pbech.setAlgorithm(digest);
 pbech.setIterations(iterations);
 pbech.setSaltLength(saltLength);
 String storedCredential = pbech.mutate(PWD);
-Assert.assertTrue(pbech.matches(PWD, storedCredential));
+Assert.assertTrue("[" + digest + "] [" + saltLength + "] [" + 
iterations + "] [" + PWD +
+"] [" + storedCredential +"]", pbech.matches(PWD, 
storedCredential));
 }
 }



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1705232 - in /tomcat/tc8.0.x/trunk: ./ test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java

[markt]

Author: markt
Date: Fri Sep 25 07:14:53 2015
New Revision: 1705232

URL: http://svn.apache.org/viewvc?rev=1705232=rev
Log:
Provide state info if test fails (it failed on Gump but I have no idea why)

Modified:
tomcat/tc8.0.x/trunk/   (props changed)

tomcat/tc8.0.x/trunk/test/org/apache/catalina/realm/TestSecretKeyCredentialHandler.java

Propchange: tomcat/tc8.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Fri Sep 25 07:14:53 2015
@@ -1 +1 @@
-/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,1640083-1640084,1640088,1640275,1640322,1640347,1640361,1640365,1640403,1640410,1640652,1640655-1640658,1640688,1640700-1640883,1640903,1640976,1640978,1641000,1641026,1641038-1641039,1641051-1641052,1641058,1641064,1641300,1641369,1641374,1641380,1641486,1641634,1641656-1641692,1641704,1641707-1641718,1641720-1641722,1641735,1641981,1642233,1642280,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1642766,1643002,1643045,1643054-1643055,1643066,1643121,1643128,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643536,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814,1643937,1643963,1644017,1644169,1644201-1644203,1644321,1644323,1644516,1644523,1644529,1644535,1644730,1644768,1644784-1644785,1644790,1644793,1644815,1644884,1644886,1644890,1644892
 
,1644910,1644924,1644929-1644930,1644935,1644989,1645011,1645247,1645355,1645357-1645358,1645455,1645465,1645469,1645471,1645473,1645475,1645486-1645488,1645626,1645641,1645685,1645743,1645763,1645951-1645953,1645955,1645993,1646098-1646106,1646178,1646220,1646302,1646304,1646420,1646470-1646471,1646476,1646559,1646717-1646723,1646773,1647026,1647042,1647530,1647655,1648304,1648815,1648907,1649973,1650081,1650365,1651116,1651120,1651280,1651470,1652938,1652970,1653041,1653471,1653550,1653574,1653797,1653815-1653816,1653819,1653840,1653857,1653888,1653972,1654013,1654030,1654050,1654123,1654148,1654159,1654513,1654515,1654517,1654522,1654524,1654725,1654735,1654766,1654785,1654851-1654852,1654978,1655122-1655124,1655126-1655127,1655129-1655130,1655132-1655133,1655312,1655351,1655438,1655441,1655454,168,1656087,1656299,1656319,1656331,1656345,1656350,1656590,1656648-1656650,1656657,1657041,1657054,1657374,1657492,1657510,1657565,1657580,1657584,1657586,1657589,1657592,1657607,1657
 
609,1657682,1657907,1658207,1658734,1658781,1658790,1658799,1658802,1658804,1658833,1658840,1658966,1659043,1659053,1659059,1659188-1659189,1659216,1659263,1659293,1659304,1659306-1659307,1659382,1659384,1659428,1659471,1659486,1659505,1659516,1659521,1659524,1659559,1659562,1659803,1659806,1659814,1659833,1659862,1659905,1659919,1659948,1659967,1659983-1659984,1660060,1660074,1660077,1660133,1660168,1660331-1660332,1660353,1660358,1660924,1661386,1661867,1661972,1661990,1662200,1662308-1662309,1662548,1662614,1662736,1662985,1662988-1662989,1663264,1663277,1663298,1663534,1663562,1663676,1663715,1663754,1663768,1663772,1663781,1663893,1663995,1664143,1664163,1664174,1664301,1664317,1664347,1664657,1664659,1664710,1664863-1664864,1664866,1665085,1665292,1665559,1665653,1665661,1665672,1665694,1665697,1665736,1665779,1665976-1665977,1665980-1665981,1665985-1665986,1665989,1665998,1666004,1666008,1666013,1666017,1666024,1666116,1666386-1666387,1666494,1666496,1666552,1666569,1666579,1
 
37,149,1666757,1666966,1666972,1666985,1666995,1666997,1667292,1667402,1667406,1667546,1667615,1667630,1667636,1667688,1667764,1667871,1668026,1668135,1668193,1668593,1668596,1668630,1668639,1668843,1669353,1669370,1669451,1669800,1669838,1669876,1669882,1670394,1670433,1670591,1670598-1670600,1670610,1670631,1670719,1670724,1670726,1670730,1670940,1671112,1672272,1672284,1673754,1674294,1675461,1675486,1675594,1675830,1676231,1676250-1676251,1676364,1676381,1676393,1676479,1676525,1676552,1676615,1676630,1676634,1676721,1676926,1676943,1677140,1677802,1678011,1678162,1678174,1678339,1678426-1678427,1678694,1678701,1679534,1679708,1679710,1679716,1680034,1680246,1681056,1681123,1681138,1681280,1681283,1681286,1681450,1681697,1681701,1681729,1681770,1681779,1681793,1681807,1681837-1681838,1681854,1681862,1681958,1682028,1682033,1682311,1682315,1682317,1682320,1682324,1682330,1682842,1684172,1684366,1684383,1684526-1684527,1684549-1684550,1685556,1685591,1685739,1685744,168577
 

svn commit: r1705233 - /tomcat/tc7.0.x/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java

[markt]

Author: markt
Date: Fri Sep 25 07:18:42 2015
New Revision: 1705233

URL: http://svn.apache.org/viewvc?rev=1705233=rev
Log:
Fix test broken during refactoring to add support for parallel class loading

Modified:

tomcat/tc7.0.x/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java

Modified: 
tomcat/tc7.0.x/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java?rev=1705233=1705232=1705233=diff
==
--- 
tomcat/tc7.0.x/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java
 (original)
+++ 
tomcat/tc7.0.x/trunk/test/org/apache/catalina/loader/TestWebappClassLoaderWeaving.java
 Fri Sep 25 07:18:42 2015
@@ -69,7 +69,7 @@ public class TestWebappClassLoaderWeavin
 
 private Tomcat tomcat;
 private Context context;
-private WebappClassLoaderBase loader;
+private WebappClassLoader loader;
 
 @Before
 @Override
@@ -83,9 +83,9 @@ public class TestWebappClassLoaderWeavin
 
 ClassLoader loader = this.context.getLoader().getClassLoader();
 assertNotNull("The class loader should not be null.", loader);
-assertSame("The class loader is not correct.", 
WebappClassLoaderBase.class, loader.getClass());
+assertSame("The class loader is not correct.", 
WebappClassLoader.class, loader.getClass());
 
-this.loader = (WebappClassLoaderBase) loader;
+this.loader = (WebappClassLoader) loader;
 
 }
 
@@ -250,7 +250,7 @@ public class TestWebappClassLoaderWeavin
 result = invokeDoMethodOnClass(this.loader, "TesterUnweavedClass");
 assertEquals("The second result is not correct.", "Hello, Weaver #2!", 
result);
 
-WebappClassLoader copiedLoader = (WebappClassLoader) 
this.loader.copyWithoutTransformers();
+WebappClassLoader copiedLoader = this.loader.copyWithoutTransformers();
 
 result = invokeDoMethodOnClass(copiedLoader, "TesterNeverWeavedClass");
 assertEquals("The third result is not correct.", "This will never be 
weaved.", result);



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1705238 - /tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/InternalAprInputBuffer.java

[markt]

Author: markt
Date: Fri Sep 25 07:31:40 2015
New Revision: 1705238

URL: http://svn.apache.org/viewvc?rev=1705238=rev
Log:
Fix an Eclipse nag, primarily to trigger a new CI build

Modified:

tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/InternalAprInputBuffer.java

Modified: 
tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/InternalAprInputBuffer.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/InternalAprInputBuffer.java?rev=1705238=1705237=1705238=diff
==
--- 
tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/InternalAprInputBuffer.java 
(original)
+++ 
tomcat/tc7.0.x/trunk/java/org/apache/coyote/http11/InternalAprInputBuffer.java 
Fri Sep 25 07:31:40 2015
@@ -87,7 +87,7 @@ public class InternalAprInputBuffer exte
  * Underlying socket.
  */
 private long socket;
-private SocketWrapper wrapper;
+private SocketWrapper wrapper;
 
 
 // - Public Methods



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: AJP Protocol enhancements

[Mark Thomas]

On 24/09/2015 14:52, Andrew Carr wrote:
>>
>>
>>> I have been following the AJP enhancements for a long time and it seems
>> the
>>> protocol is stagnant.
>>
>> I prefer 'mature'.
>>
> 
> Apologies.  Mature is a much more appropriate word.
> 
> 
>>> I do see some updates in the last year to the
>>> enhancements page and some of the bugs, but there is not much activity.
>> I
>>> search for "enhancements" under the Tomcat Connectors project in Bugzilla
>>> because it does not seem as though there is a specific category for AJP
>>> Protocol enhancements.  I am very interested in starting work on the AJP
>>> Protocol enhancements.  It seems like the protocol needs a clear
>>> specification.
>>
>> We have this:
>> http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html
>>
>> I'd like to see that in more of an RFC style but the content (speaking
>> as someone who spends a lot of time reading and then implementing specs)
>> is pretty good.
>>
> 
> I have reviewed the page you mentioned, in detail.  I was confused however,
> because of the other page with ideas for the protocol enhancements.  I see
> where you cleared that up below.  Maybe we need to state that the "ajpv13a"
> page (or a new page) is the definitive resource for the new protocol
> declaration.
> 
> 
>>
>>> Wouldn't a JSR for the protocol specification make sense?   Aren't there
>>> enough people on this list with a clear enough understanding to
>> facilitate
>>> introducing AJP 1.4 (or 2.0) as a JSR?
>>
>> -1.
>>
>> I don't believe that going via the JCP would add anything beneficial.
>>
> 
> I am in agreement with this and Rainer's comments.  I was suggesting JCP as
> a possibility, RFC style is perfectly O.K. as well.  My goal is something
> formalized.  An RFC for AJP1.3a or AJP1.4 or 2, whatever, would accomplish
> the same thing.
> 
> 
>>> Even if we don't go the JCP route, shouldn't we work on the protocol?  It
>>> needs updating, imho.
>>
>> I do agree that there is benefit to updating the AJP protocol. Adding
>> support for HTTP upgrade is the feature that pops to mind immediately. I
>> also recall that we have used custom request attributes to pass
>> additional attributes that didn't have a dedicated protocol attribute.
>>
>>> If you think I am wrong, please explain why, so that I may learn from the
>>> experience.  I have searched the lists and the interwebs for information
>> on
>>> this and I am having a hard time finding it.  I have also been looking
>> for
>>> a place in the Tomcat project to dig in for 3 years, and I believe I have
>>> finally found that place.
>>>
>>> Some other facts to support my argument about generating a specification,
>>> it appears the enhancements to create the next AJP protocol are in
>> multiple
>>> locations.  I know there is currently the AJP Extension Proposal, but
>> what
>>> about all of the AJP14 stuff floating around?
>>>
>>> https://tomcat.apache.org/connectors-doc/ajp/ajpv13ext.html
>>>
>> https://archive.apache.org/dist/tomcat/tomcat-connectors/jk2/v2.0.0/doc/common/AJPv14-proposal.html
>>
>> Those look to be largely the same ideas and date from roughly the same
>> time (10+ years ago).
>>
> 
> Again, I agree, just think there should be a definitive definition of the
> protocol.
> 
> 
>>
>>> Please let me know your thoughts and concerns on enhancing the AJP
>> protocol
>>> and possibly introducing a new version with new features.
>>
>> I think there is a clear case for a new version. The first thing to do
>> would be to pull all the ideas together in one place (I'm thinking the
>> wiki), agree what needs to be in AJP.next and then work on updating the
>> specification to accommodate it.
>>
>> Regarding the wiki, the current Tomcat wiki is hosted on a system that
>> be be very slow (minutes) to process updates. I think we should create a
>> new wiki instance on the cwiki server that is a lot faster when editing.
>>
> 
> Should gathering ideas in the wiki wait until after it is moved to a new
> instance, or will it all be migrated (so starting now on the new page would
> be ok?)

Long term, we probably do need to migrate the wiki. Short term we can
use the new instance just for this.

Mark


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: AJP Protocol enhancements

[Mark Thomas]

On 24/09/2015 14:48, Rémy Maucherat wrote:
> 2015-09-24 15:13 GMT+02:00 Andrew Carr :
> 
>> On Thu, Sep 24, 2015 at 4:52 AM, Rémy Maucherat  wrote:
>>
>>> 2015-09-24 11:04 GMT+02:00 Mark Thomas :
>>>
 I think there is a clear case for a new version. The first thing to do
 would be to pull all the ideas together in one place (I'm thinking the
 wiki), agree what needs to be in AJP.next and then work on updating the
 specification to accommodate it.

 Regarding the wiki, the current Tomcat wiki is hosted on a system that
 be be very slow (minutes) to process updates. I think we should create
>> a
 new wiki instance on the cwiki server that is a lot faster when
>> editing.

>>> I rather like the idea of HTTP/2 as a proxy protocol. Did I miss
>>> something
>>> and what would a AJP.next bring over it ?
>>>
>> Rémy,
>> Why wouldn't we offer a new AJP (AJP/2 Maybe?) alongside HTTP/2?  The
>> current setup (as you all know) allows for HTTP proxying and AJP proxying.
>> You suggest HTTP/2 as the proxy protocol with no AJP?
>>
>> Yes, maybe HTTP/2 could be used as the proxy transport protocol:
>- Encryption possible
> - Message based
> - Header compression
> - Flow control
> - Multiplexing
> - Etc
> 
> That would save a significant amount of effort specifying and implementing
> [assuming it really does everything that is needed ...] especially if proxy
> servers start adding HTTP/2 as a supported protocol for backend server
> communication.

I'm not so sure. HTTP/2 explicitly doesn't support HTTP upgrade. The
HTTP/2 spec expects protocols like WebSocket to use ALPN. Despite this,
there has been work to try and layer WebSocket on top of HTTP/2.

At this point in time proxying WebSocket is tricky. httpd's WebSocket
proxy support makes assumptions that aren't always valid.

General support for proxying HTTP upgrade would be a good thing and
right now AJP looks like the simplest way for us to make this happen.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

buildbot exception in ASF Buildbot on tomcat-7-trunk

[buildbot]

The Buildbot has detected a build exception on builder tomcat-7-trunk while 
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/tomcat-7-trunk/builds/93

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-7-commit' 
triggered this build
Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1705233
Blamelist: markt

BUILD FAILED: exception upload_2

Sincerely,
 -The Buildbot




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

buildbot success in ASF Buildbot on tomcat-7-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-7-trunk while 
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/tomcat-7-trunk/builds/94

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-7-commit' 
triggered this build
Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1705238
Blamelist: markt

Build succeeded!

Sincerely,
 -The Buildbot




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: AJP Protocol enhancements

[Rémy Maucherat]

2015-09-25 9:29 GMT+02:00 Mark Thomas :

> I'm not so sure. HTTP/2 explicitly doesn't support HTTP upgrade. The
> HTTP/2 spec expects protocols like WebSocket to use ALPN. Despite this,
> there has been work to try and layer WebSocket on top of HTTP/2.
>
> At this point in time proxying WebSocket is tricky. httpd's WebSocket
> proxy support makes assumptions that aren't always valid.
>
> General support for proxying HTTP upgrade would be a good thing and
> right now AJP looks like the simplest way for us to make this happen.
>
> Most likely a HTTP/2 proxy will still be a legacy HTTP/1.1 proxy as well.
The main problem with the AJP.next plan is that by the time you release
something many will be using HTTP/2. HTTP/2 is more important than the rest
moving forward, and encapsulating in AJP it would likely be inefficient
(basically, zillions of messages).

OTOH, reversing the problem, AJP.next can be a HTTP/2 transport where you
specify encapsulation of HTTP/1.1 and its upgrade. That could be more
transparent and make configuration much cooler: unless the Tomcat connector
gets some encapsulated requests, it could still act as a normal HTTP/2
connector.

Rémy

Re: AJP Protocol enhancements

[jean-frederic clere]

On 09/25/2015 10:51 AM, Rémy Maucherat wrote:

2015-09-25 9:29 GMT+02:00 Mark Thomas :


I'm not so sure. HTTP/2 explicitly doesn't support HTTP upgrade. The
HTTP/2 spec expects protocols like WebSocket to use ALPN. Despite this,
there has been work to try and layer WebSocket on top of HTTP/2.

At this point in time proxying WebSocket is tricky. httpd's WebSocket
proxy support makes assumptions that aren't always valid.

General support for proxying HTTP upgrade would be a good thing and
right now AJP looks like the simplest way for us to make this happen.

Most likely a HTTP/2 proxy will still be a legacy HTTP/1.1 proxy as well.

The main problem with the AJP.next plan is that by the time you release
something many will be using HTTP/2. HTTP/2 is more important than the rest
moving forward, and encapsulating in AJP it would likely be inefficient
(basically, zillions of messages).

OTOH, reversing the problem, AJP.next can be a HTTP/2 transport where you
specify encapsulation of HTTP/1.1 and its upgrade. That could be more
transparent and make configuration much cooler: unless the Tomcat connector
gets some encapsulated requests, it could still act as a normal HTTP/2
connector.


Basically HTTP/2 requires SSL: the proxies are doing the TLS/SSL 
termination and send HTTP/1.1 (or AJP) to the back-ends, you can't 
upgrade for the back-end.


If the proxy would only do the TLS/SSL termination then you need 
something like HTTP/2 protocol between the back-end and the proxy.
I think a customized HTTP/2 connector could do that, so there is no need 
of AJP+ protocol.


If you think of upgrade to websockets it is for already existing 
applications and there proxying isn't that good (mod_proxy_wstunnel is 
just a tunnel it doesn't care about the contents once upgraded). So 
adding upgrade to AJP won't help much.


Additionally I think websockets via upgrade is dead, there won't be new 
developments there.


I would just let AJP dying in peace.

Cheers

Jean-Frederic

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: AJP Protocol enhancements

[Jess Holle]

The one really compelling /usability /bit about AJP proxying is that 
requests look like you're in/at the web server in question and receiving 
requests directly from the client of the web server.


The fact that you are not is completely and utterly transparent to your 
web application code.


The same cannot be said for HTTP proxying, which throws the proxying 
details in your face and leaves you scrambling with various valves, etc, 
to hide these details from web applications that care about the logical, 
not physical, truth of the situation.


--
Jess Holle