Re: [jetty-users] shibboleth idp webapp under jetty 12.0.7
Paul, Jetty will extract from to a temp web-inf directory to avoid the jar inside war class loading issues when a war file is not unpacked. It should not be doing this if the webapp is unpacked. It should definitely not put both on the classpath. I think we may have a bug here. We will investigate. To better track this, can you open an issue <https://github.com/jetty/jetty.project/issues> and paste your message in as the description. regards On Tue, 26 Mar 2024 at 04:54, Paul B. Henson via jetty-users < jetty-users@eclipse.org> wrote: > I'm currently running the shibboleth idp webapp 4 under jetty 9, and > trying to migrate to idp 5 using jetty 12. I've run into an odd problem, > I get the following error: > > Caused by: org.springframework.beans.factory.BeanCreationException: Error > creating bean with name 'flowRegistry' defined in class path resource > [net/shibboleth/idp/conf/webflow-config.xml]: Illegal attempt to register > pre-existing flow ID 'authn/DuoOIDC'via resource: URL > [jar:file:/var/lib/jetty/tmp/jetty-127_0_0_1-80-idp_war-_idp-any-10824638488520165161/webapp/WEB-INF/lib/idp-plugin-duo-impl-2.0.0.jar!/META-INF/net/shibboleth/idp/flows/authn/DuoOIDC/duo-oidc-authn-flow.xml] > > This generally occurs if there are multiple copies of the jar on the > classpath, such as if the war accidentally included more than one (which > isn't the case here). > > The deployment descriptor for the idp app is: > > > /opt/shibboleth-idp/war/idp.war > /idp > false > false > true > > > which is the recommended config per the idp documentation. With this > config, I see two separate copies of the jar in the jetty tmp directory, > one in webapp and one in webinf: > > # find | grep duo > > ./webapp/WEB-INF/lib/idp-plugin-duo-nimbus-client-impl-2.0.0.jar > > ./webapp/WEB-INF/lib/idp-plugin-duo-impl-2.0.0.jar > > ./webapp/WEB-INF/lib/idp-plugin-duo-api-2.0.0.jar > > ./webinf/WEB-INF/lib/idp-plugin-duo-nimbus-client-impl-2.0.0.jar > > ./webinf/WEB-INF/lib/idp-plugin-duo-impl-2.0.0.jar > > ./webinf/WEB-INF/lib/idp-plugin-duo-api-2.0.0.jar > > > If I update the config and set copyWebInf=false, there's only one copy > of the jar in the tmp directory (in webapp) and everything works fine. > > Looking at my existing jetty 9 deployment, there's only the webinf > directory in the tmp dir, not the webapp one. If I update my jetty 9 > config and set extractWAR=true, then I get the same multiple copies (one > in webapp, one in webinf) as I do with extractWAR=false in jetty 12, > although this doesn't cause an error under jetty 9. If I set > extractWAR=true under jetty 12, I see no change in the content of the > tmp directory as compared to extractWAR=false. > > So I'm confused. Why is jetty 12 apparently extracting the war when > extractWAR=false? And when it does, how come the same jar file seems to > get processed twice, when that doesn't occur under jetty 9 with > extractWAR=true? > > I'm not sure if I'm hitting a bug or have something misconfigured. It > seems to be working now with copyWebInf=false, but that also seems more > of a workaround than a resolution. This feels buggy, that jetty is > extracting the war when it shouldn't be, and also loading the same jars > from two different places when the war is extracted *and* copyWebInf=true. > But I'm far from a jetty expert :). > > Thanks for any hints... > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Problem reading POST body with embedded Jetty 12.0.x
Silvio, Let's get your existing code working but then I'd really like to show you how you can use jetty-12 handlers to do that expansion for you prior to any buffering and/or blocking input streams. cheers On Tue, 12 Sept 2023 at 03:47, Simone Bordet via jetty-users < jetty-users@eclipse.org> wrote: > Hi, > > On Mon, Sep 11, 2023 at 2:16 PM Silvio Bierman via jetty-users > wrote: > > > > It appears that all handling of POST requests with ZIP-content as > > payload in our application is broken with Jetty 12 (I tried both 12.0.0 > > and 12.0.1). We use an embedded Jetty-12 with ee10 and http/2. > > > > Using Jetty 11 the code works as expected. > > > > We post a ZIP-file from the command line using Curl to the application. > > The handling code wraps request.getInputStream in a BufferedInputStream > > wrapped in a ZipInputStream and starts reading ZipEntry objects with > > getNextEntry until this returns null. With Jetty 12 this code only > > manages to read the first part of the POST-body and then blocks > > indefinitely. This is not a multi-part request, the ZIP-content is > > simply used as the request payload. > > > > We have similar handling of ZIP-files posted from inside HTML pages > > (using JS FormData and XmlHttpRequest) and the same thing happens there. > > In this case the FormData is used to create a multi-part POST. > > > > Each time the first parts of the payload seems to be handled correctly. > > The initial entries are expanded and written to server side files > > correctly. > > > > No exceptions occur. The code just seems to block indefinitely with no > > CPU activity. > > > > Any ideas? Perhaps there is something wrong with our embedding code? > > Please open an issue with the code example, where it throws, and the > stack trace. > GH issues are better for this kind of analysis. > > Thanks! > > -- > Simone Bordet > > http://cometd.org > http://webtide.com > Developer advice, training, services and support > from the Jetty & CometD experts. > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Exception in Jetty 12.0.1
ndle(ContextHandlerCollection.java:177) >> at org.eclipse.jetty.server.Handler$Wrapper.handle(Handler.java:712) >> at org.eclipse.jetty.server.Server.handle(Server.java:176) >> at >> org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:648) >> at >> org.eclipse.jetty.util.thread.Invocable$ReadyTask.run(Invocable.java:105) >> at >> org.eclipse.jetty.http2.server.internal.HttpStreamOverHTTP2$1.run(HttpStreamOverHTTP2.java:129) >> at >> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:478) >> at >> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:441) >> at >> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:293) >> at >> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.produce(AdaptiveExecutionStrategy.java:195) >> at >> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:211) >> at >> org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:158) >> at >> org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:449) >> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100) >> at >> org.eclipse.jetty.io.ssl.SslConnection$SslEndPoint.onFillable(SslConnection.java:554) >> at >> org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:373) >> at >> org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:146) >> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100) >> at >> org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53) >> at >> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:478) >> at >> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:441) >> at >> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:293) >> at >> org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:201) >> at >> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:410) >> at >> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:969) >> at >> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1194) >> at >> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1149) >> at java.base/java.lang.Thread.run(Thread.java:1623) >> >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> >> >> ___ >> jetty-users mailing listjetty-us...@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> >> >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 12 return wrong Host header?
Actually,
I think Uwe's and Silvio's problems are similar but different.
Silvio, you have no forwarded request customizer headers and a real
"demo.jambo.software:8443" as the host header value. This could be a http2
issue in recreating that header.
Uwe's issue is more about the customizer.
So Silvio, perhaps open a second issue?
cheers
P.S. We expect at least a monthly cadence of 12.0.x releases.
On Sun, 13 Aug 2023 at 08:52, Greg Wilkins wrote:
> Silvio,
>
> I'll respond more in Uwe's issue. Please post your details there to help
> the triage.
>
> cheers
>
>
>
> On Sun, 13 Aug 2023 at 05:19, Uwe Schindler via jetty-users <
> jetty-users@eclipse.org> wrote:
>
>> I opened: https://github.com/eclipse/jetty.project/issues/10304
>> Am 12.08.2023 um 19:30 schrieb Uwe Schindler via jetty-users:
>>
>> I have seen the same after upgrading my project to Java 12. The problem
>> is that all Customizers are not able to correctly set the port number.
>>
>> This is a blocker issue, because it makes it impossible to setup this
>> common setup:
>>
>>- NGINX as user facing web server with HTTPS enabled
>>- NGINX forwarding the requests to jetty listen only on localhost
>>with some arbitrary port number (in my case 8081). NGINX sets the
>> following
>>headers: X-Forwarded-For, X-Forwarded-Proto, original "Host" header as
>> sent
>>by client (no rewriting)
>>- Jetty with: http_config.addCustomizer(new
>>ForwardedRequestCustomizer());
>>- Jetty 10 works fine it reads the clien't IP address and all other
>>information from X-Forwarded-For, the scheme is read from
>>X-Forwarded-Proto, and host header is coming from "Host" header. It also
>>extracts the port number from the host.
>>- Jetty 12 is setup in same way, it successfully extracts the
>>client's IP address and also it returns secure=true and uses "https://;
>>for javax.servlet.HttServletRequest#getRequestURL(). But it always adds
>> its
>>own private port number. I also tried to use setForcedHost("xyz:443") to
>>make sure it sees a port number. It still constructs all URLs with port
>>number 8081 where it listens on.
>>
>> I will open a bug report. From my experience the "customize()" method in
>> the RequestCustomizer does everything right also also returns the port
>> number, but the javax.servlet API seems to still use the port number used
>> by the connector's channel.
>>
>> I reverted back to Jetty 10. This won't work here. If you have any
>> suggestion to get the port corrcet, tell me, everything like subclassing
>> and implementing my own cutsomizer did not work. I was not able to debug
>> through everything and figure out where the listener port gets injected
>> again.
>>
>> I can say: With current status Jetty 12 is unuseable with the common
>> proxy setup using ForwardedRequestCustomizer as it tried to always inject
>> its own hidden/private port number instead of the default for the port as
>> negotiated by client/proxy with the Host header.
>>
>> --
>> Uwe schindleruschind...@apache.org
>> ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
>> Bremen, Germanyhttps://lucene.apache.org/https://solr.apache.org/
>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
>
>
> --
> Greg Wilkins CTO http://webtide.com
>
--
Greg Wilkins CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 12 return wrong Host header?
Silvio,
I'll respond more in Uwe's issue. Please post your details there to help
the triage.
cheers
On Sun, 13 Aug 2023 at 05:19, Uwe Schindler via jetty-users <
jetty-users@eclipse.org> wrote:
> I opened: https://github.com/eclipse/jetty.project/issues/10304
> Am 12.08.2023 um 19:30 schrieb Uwe Schindler via jetty-users:
>
> I have seen the same after upgrading my project to Java 12. The problem is
> that all Customizers are not able to correctly set the port number.
>
> This is a blocker issue, because it makes it impossible to setup this
> common setup:
>
>- NGINX as user facing web server with HTTPS enabled
>- NGINX forwarding the requests to jetty listen only on localhost with
>some arbitrary port number (in my case 8081). NGINX sets the following
>headers: X-Forwarded-For, X-Forwarded-Proto, original "Host" header as sent
>by client (no rewriting)
>- Jetty with: http_config.addCustomizer(new
>ForwardedRequestCustomizer());
>- Jetty 10 works fine it reads the clien't IP address and all other
>information from X-Forwarded-For, the scheme is read from
>X-Forwarded-Proto, and host header is coming from "Host" header. It also
>extracts the port number from the host.
>- Jetty 12 is setup in same way, it successfully extracts the client's
>IP address and also it returns secure=true and uses "https://; for
>javax.servlet.HttServletRequest#getRequestURL(). But it always adds its own
>private port number. I also tried to use setForcedHost("xyz:443") to make
>sure it sees a port number. It still constructs all URLs with port number
>8081 where it listens on.
>
> I will open a bug report. From my experience the "customize()" method in
> the RequestCustomizer does everything right also also returns the port
> number, but the javax.servlet API seems to still use the port number used
> by the connector's channel.
>
> I reverted back to Jetty 10. This won't work here. If you have any
> suggestion to get the port corrcet, tell me, everything like subclassing
> and implementing my own cutsomizer did not work. I was not able to debug
> through everything and figure out where the listener port gets injected
> again.
>
> I can say: With current status Jetty 12 is unuseable with the common proxy
> setup using ForwardedRequestCustomizer as it tried to always inject its own
> hidden/private port number instead of the default for the port as
> negotiated by client/proxy with the Host header.
>
> --
> Uwe schindleruschind...@apache.org
> ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
> Bremen, Germanyhttps://lucene.apache.org/https://solr.apache.org/
>
> _______
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
--
Greg Wilkins CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 12 return wrong Host header?
Silvio,
The host header should contain the host and port as used by the client.
Thus if the request goes to the default port and is forward you a different
port, the host header should not have the port in it, or at least only the
default port.
Are you sure the client is using the default port and not going direct you
the server?
Can you give us a bit more info:
+ Uri and headers as sent by the client
+ Uri and headers as received by jetty
+ The actual values you get from the various request methods
Cheers
On Fri, Aug 11, 2023, 21:34 Silvio Bierman via jetty-users <
jetty-users@eclipse.org> wrote:
> Hello all,
>
> I have encountered what I think is a bug in Jetty 12 but I would like to
> check here if that is actually true.
>
> I use port forwarding to forward HTTP requests from port 443 to 8443.
> Requests arrive at the default port without an explicit port number in
> the URL so
>
> request.getRequestURL().toString
>
> does not show a port number. But
>
> request.getHeader("Host")
>
> returns the host name including the port number. This makes it
> impossible to distinguish requests with explicit ports from requests
> without these. Jetty 11 does not show this same behaviour.
>
> Cheers,
>
> Silvio
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] SolrJ/Solr: HTTP protocol violation: Authentication challenge without WWW-Authenticate header
Shawn, The other thing to do is to bisect the changes from a jetty-9.4.x that you think works to jetty-9.4.48 that you think does not work. There are not that many changes in jetty 9.4, so it should not be too much work... but it will be some effort which is why we don't offer open source support on jetty-9.4 anymore - we just don't have the cycles to track down things like this (especially when more often than not, after doing the work we find it is not a bug in jetty). If you can identify an actual commit that you think is bad, then that will help working out what the issue is. Of course the other thing to do is to get somebody to take out a commercial support agreement, so we can put in the effort to help debug this issue (even if it turns out to be not jetty). cheers On Fri, 2 Jun 2023 at 00:43, Shawn Heisey wrote: > On 6/1/23 15:45, Jesse McConnell wrote: > > Your best bet would be to do at Greg said and capture the actual request > > failing on the wire using wireshark or tcpdump, or get a > > HttpChannel.Listener[1] set up in the server so you can see what is > > happening there. > > I do not have access to the private key for the TLS certificate. > > Even if I did, I have found that Wireshark cannot decrypt HTTPS if a > modern cipher is being used. Solr 9 requires at least Java 11, and that > is the version being used. I would expect Java 11, Jetty Server 9, and > Jetty client 10 to be utilizing a modern cipher. Browser connections to > Solr are using TLS 1.2 with the cipher named > TLS_ECDHE_RSA_WITH_AES256_GCM_SHA384. > > Thanks, > Shawn > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] SolrJ/Solr: HTTP protocol violation: Authentication challenge without WWW-Authenticate header
If I understand correctly, the situation is that you are sending many requests, all with credentials encoded in the headers. Occasionally a 401 response is received that does not have the WWW-Authenticate header. This would need for the request to have failed authentication (when many requests with same credentials had passed) and for the resulting 401 response to have been incorrectly generated by jetty. It seems very unlikely that the one request that has a problem with auth, also tickles some issue to make a bad challenge. More likely something unrelated to authentication is emitting a spurious 401 response? Can you capture the full headers of the bad 401? On Wed, 31 May 2023 at 05:52, Shawn Heisey wrote: > On 5/30/23 18:48, Shawn Heisey wrote: > > I am trying one more thing ... setting the client to use http/1.1. I > > remember we had some issues with Solr where http2 wasn't working right, > > and I think the final fix for that was upgrading Jetty. > > This did not help. It still randomly (though not very frequently) > throws that exception about authentication. > > I do think I was on the right track, just not looking in exactly the > right place. > > I set an option when building the Solr client for indexing that SHOULD > have forced all updates to be routed to shard leaders. > > Turns out that option doesn't actually do anything. Which I think is a > bug. > > So sometimes updates went to a replica that wasn't leader. And when > that happens, Solr forwards the request to the right index. That > forwarding is done using HTTP/2, and we have seen evidence that HTTP/2 > on Solr sometimes has weird issues. > > There is a different and very similarly named option that DOES force the > client to send to leaders only. > > So I am using http/1.1 in conjunction with that correct option. Bonus > ... the indexing is happening faster than before, because Solr doesn't > ever need to forward requests to another server. I should find out in > the next hour or so whether it actually helped. > > I do think that if I can get them to upgrade Solr so it's using Jetty > 10, the problem will evaporate. > > Thanks, > Shawn > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] jetty-openid : honouring expiry time
Andrew, sounds like a feature that might be developed. Can you please open an issue to request this. On Thu, 2 Mar 2023 at 16:15, Andrew McGuinness < and...@dev.sunshineriding.co.uk> wrote: > I've started using jetty-openid for authentication (with jetty 10), and as > far as I can see, once a user has authenticated successfully with openid, > their session stays authenticated for the lifetime of the session (based on > idle time or cookie exipry). > > I would have thought ideally the session should only remain authenticated > until the expiry time returned with the access token is reached. At that > point the refresh token should be used to obtain a new valid access token. > > Does that sound right? Is it a feature that might be developed? > > > > > > > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Threading model (was Re: Jetty 12 schedule?_
On Thu, 10 Nov 2022 at 23:53, Cantor, Scott wrote: > > What we're concerned about is the drumbeat that a non-async-using servlet > request that's just executing methods on objects via the stack could start > out on one thread and switch threads in the middle. And I just don't see > how that's remotely possible or sane. And if it is, the spec went to a very > bad place and a lot of software is screwed, not just ours. > To my knowledge that cannot happen at least not with normal threads. Perhaps in future with virtual threads, then threadlocals might be more of a problem, but their usage will be optional in Jetty. -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Threading model (was Re: Jetty 12 schedule?_
On Thu, 10 Nov 2022 at 12:29, Cantor, Scott wrote: > >The proper way is to use the request / response objects as passed to > > you, and not hold onto them. > > That would imply that one has to immediate extract every possible bit from > them and construct a new façade for the data before one's servlet method > even calls another object. That's a pretty huge step backward, if true. > Scott, it is typical to handle requests with multi classes, potentially calling deep into a code base. Often these calls will accept the request and/or response as an argument and that is a reasonable style as it makes it very clear that the call is part of a request/response calling cycle. Problems start to occur when a request/response is wrapped in another object that abstracts away from the request response paradigm and just looks like some dataful object (which just happens to be backed by data a request). Such objects can easily be put into persistent data structures that have no lifecycle relationship to the original request. So the antipattern is to facade a request into a non-request like API. If your facades do look like requests and their lifecycle is apparent, then that is a reasonable abstraction. regards -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 12 schedule?
Scott, I'm not understanding how your facades work or why exactly they are needed? Can you give some examples? Why can you not just deploy old javax.* code to one context and new jakarta.* code to a different one. cheers On Thu, 10 Nov 2022 at 07:58, Cantor, Scott wrote: > >jetty-12 is dependent on neither namespace, but can deploy contexts > > that are dependent on javax.* or jakarta.* > > There are, though, two incompatible jakarta-namespaced APIs, Servlet 5 and > 6. That's where we're having issues because we implement facades for the > APIs that can't load on both at once. > > We can implement separate ones for 5 and 6 (and thus Jetty 11 and 12) but > we're not sure how we'll manage it if we do. > > We haven't really looked into how 12 is going to do what it does yet, > we're just assessing options and knowing when 12 will likely come out helps > with our planning. > > Most projects are just worried about the APIs they *call* but when you > also implement HttpServletRequest/Response, it's not that simple obviously, > and we had no idea Servlet 6.0 actually removed things from 5.0 until today. > > -- Scott > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 12 schedule?
On Thu, 10 Nov 2022 at 07:08, Cantor, Scott wrote: > > I'm refering specifically to the fact that Servlet 5.0 and 6.0, in the > Jakarta namespace, are not compatible because they've removed some > deprecated methods and interfaces and added others. Implementing both in > some system is problematic, at minimum. > > We haven't explored every trick of course. > Scott, jetty-10 is dependent on the javax.* namespace jetty-11 is dependent on the jakarta.* namespace jetty-12 is dependent on neither namespace, but can deploy contexts that are dependent on javax.* or jakarta.* However, you cannot mix APIs within the one context. regards -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Connection Manager
On Wed, 12 Oct 2022 at 05:13, Simone Bordet wrote: > For other protocols such as HTTP/2 or HTTP/3, adding the `Connection: > close` header will have no effect. > Thinking out loud here... Whilst there is no requirement to close a HTTP/2 or HTTP/3 connection when a "Connection: close" header is seen, I wonder if we could perhaps use that as a hint to shutdown the connection (well reduce the number of streams to 0 and let other streams complete and then close). This would be useful in graceful shutdown scenarios... but perhaps the header is the wrong way to signal that? -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] What does this exception mean?
How was the exception logged?
Normally we try to suppress such IO exceptions, as they can happen at any
time if a client closes the connection (goes into a tunnel, closes laptop
lid etc.). But perhaps this one has slipped through.
On Thu, 21 Jul 2022 at 20:48, Simone Bordet wrote:
> Hi,
>
> On Thu, Jul 21, 2022 at 12:30 PM John English
> wrote:
> > java.io.IOException: Close
> > SendCallback@7c34392e
> [PROCESSING][i=HTTP/1.1{s=302,h=5,cl=-1},cb=org.eclipse.jetty.server.HttpChannel$SendCallback@3b37d5e3
> ]
> > in state PROCESSING
>
> I'm guessing the client closed the connection while the server was
> writing a 302 redirect.
> --
> Simone Bordet
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless. Victoria Livschitz
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
--
Greg Wilkins CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] ProxyServlet & chunking
You are able to call response.flushBuffers() to flush any buffered content. On Tue, 12 July 2022, 14:25 LP via jetty-users, wrote: > Hi, > > My understanding of HTTP/1.1 chunking is that it's considered to be a > hop-to-hop feature, and so if the server behind an (Async)ProxyServlet > responds with a stream of small chunks they can be buffered. This poses a > challenge for some chunking use-cases, including SSE (Server Sent Events). > One workaround I found for SSE is to send a large-ish "flush" event with > some random junk after each "real" event to push the real event through the > buffer. This works fine when the events aren't too frequent, but it's > obviously not a great solution. > > Is there any functionality available that allows for setting a timeout > in the ProxyServlet after which any buffered response content would > automatically be flushed via chunking? If not, would this be difficult to > implement? > > Jetty rules! > > Thanks, > LP > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Omit Stacktraces in error pages
Lothar, You can use a GlobalWebappConfigBinding <https://www.eclipse.org/jetty/javadoc/jetty-9/org/eclipse/jetty/deploy/bindings/GlobalWebappConfigBinding.html> in the deployer to apply an XML file to every deployed context. This should allow you to get the error page and then set the no stack field. I thought we had some doco/examples, but I'm struggling to find them. @Joakim Erdfelt do you know of any such examples? cheers On Wed, 29 Jun 2022 at 17:55, Lothar Kimmeringer wrote: > Hi, > > I'm wondering how to get Jetty to omit stack traces in error pages > globally (programmatically). I've tried to get the Server's > ErrorHandler before start up, after startup and by setting my > own in order to set showStack(false). But this has no effect > #on added web applications where own ErrorHandlers are set that > still show stack traces. > > Before I start to write a method recursively going through > the whole server searching for error handlers, what's the > "official" way of getting this configured? The documentation > I've found so far only shows how to set custom error handlers > or simply says that an error handler can be set to the server > and to contexts. > > > Thanks and cheers, Lothar > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] EXTERNAL: Re: jetty client delivers incomplete response without exception?
If the response is chunked then the EOF should trigger an error because it
does not see a final chunk.
How does your client see the end of the response? As an error?
It might be time to create an issue for this and attach the info you have.
On Mon, 27 June 2022, 17:31 Robben, Bert, wrote:
> Hi Greg,
>
>
>
> Thanks for the answer. Regarding a solution, I don’t know what we can do.
>
>
>
> We cannot set a content-length explicitly. The server is generating a very
> long reply based on many different resources. As such, the server doesn’t
> know what the content-length will be until after it has generated its huge
> reply. And we don’t want to do that because then the server needs to have
> the entire message in memory just to be able to set the header up front.
> Doing the expensive result computation twice, once to determine the size
> and a second time to send it over the network is stupid and wasteful of
> resources.
>
>
>
> Jetty server itself is already using chunked transfer encoding. Our
> application logic didn’t decide to use chunked transfer encoding. It was
> jetty server that did this. Our logic server logic is a jax-rs resource
> that just writes to the jax-rs response outputstream. From the (incomplete)
> tcpdumps that we have, we can see that Jetty server (as expected) sets the
> transfer-encoding header.
>
>
>
> 0a 58 0a 81 08 99 f2 ba 24 a1 f2 7f 08 00 45 00 .X..$.E.
>
> 0010 22 c6 bb cc 40 00 3f 06 13 dc ac 1e 8a 51 0a 81 "...@.?..Q..
>
> 0020 08 99 1f 90 a9 09 5b 94 b3 52 87 f2 1c ec 80 18 ..[..R..
>
> 0030 00 ec 6c 42 00 00 01 01 08 0a ac d7 b7 b1 ac f4 ..lB
>
> 0040 11 24 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f .$HTTP/1.1 200 O
>
> 0050 4b 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a K..Content-Type:
>
> 0060 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 6a 73 6fapplication/jso
>
> 0070 6e 0d 0a 41 63 63 65 73 73 2d 43 6f 6e 74 72 6f n..Access-Contro
>
> 0080 6c 2d 41 6c 6c 6f 77 2d 43 72 65 64 65 6e 74 69 l-Allow-Credenti
>
> 0090 61 6c 73 3a 20 74 72 75 65 0d 0a 41 63 63 65 73 als: true..Acces
>
> 00a0 73 2d 43 6f 6e 74 72 6f 6c 2d 41 6c 6c 6f 77 2d s-Control-Allow-
>
> 00b0 4d 65 74 68 6f 64 73 3a 20 47 45 54 2c 20 50 4f Methods: GET, PO
>
> 00c0 53 54 2c 20 50 55 54 2c 20 44 45 4c 45 54 45 2c ST, PUT, DELETE,
>
> 00d0 20 4f 50 54 49 4f 4e 53 2c 20 48 45 41 44 2c 20OPTIONS, HEAD,
>
> 00e0 50 41 54 43 48 0d 0a 41 63 63 65 73 73 2d 43 6f PATCH..Access-Co
>
> 00f0 6e 74 72 6f 6c 2d 41 6c 6c 6f 77 2d 48 65 61 64 ntrol-Allow-Head
>
> 0100 65 72 73 3a 20 6f 72 69 67 69 6e 2c 20 63 6f 6e ers: origin, con
>
> 0110 74 65 6e 74 2d 74 79 70 65 2c 20 61 63 63 65 70 tent-type, accep
>
> 0120 74 2c 20 61 75 74 68 6f 72 69 7a 61 74 69 6f 6e t, authorization
>
> 0130 2c 20 69 64 65 6d 70 6f 74 65 6e 63 79 5f 6b 65 , idempotency_ke
>
> 0140 79 0d 0a 41 63 63 65 73 73 2d 43 6f 6e 74 72 6f y..Access-Contro
>
> 0150 6c 2d 41 6c 6c 6f 77 2d 4f 72 69 67 69 6e 3a 20 l-Allow-Origin:
>
> 0160 2a 0d 0a 54 72 61 6e 73 66 65 72 2d 45 6e 63 6f *..Transfer-Enco
>
> 0170 64 69 6e 67 3a 20 63 68 75 6e 6b 65 64 0d 0a 0d ding: chunked...
>
> 0180 0a 32 31 34 44 0d 0a 7b 22 63 75 73 74 6f 6d 65 .214D..{"custome
>
> 0190 72 50 61 79 6d 65 6e 74 53 74 61 74 75 73 52 65 rPaymentStatusRe
>
> 01a0 70 6f 72 74 56 30 37 44 6f 63 75 6d 65 6e 74 22 portV07Document"
>
> 01b0 3a 7b 22 63 75 73 74 6f 6d 65 72 50 61 79 6d 65 :{"customerPayme
>
> 01c0 6e 74 53 74 61 74 75 73 52 65 70 6f 72 74 22 3a ntStatusReport":
>
> 01d0 7b 22 67 72 6f 75 70 48 65 61 64 65 72 22 3a 7b {"groupHeader":{
>
> 01e0 22 6d 65 73 73 61 67 65 49 64 65 6e 74 69 66 69 "messageIdentifi
>
> 01f0 63 61 74 69 6f 6e 22 3a 22 49 44 22 2c 22 63 72 cation":"ID","cr
>
> 0200 65 61 74 69 6f 6e 44 61 74 65 54 69 6d 65 22 3a eationDateTime":
>
> …
>
>
>
> We tried to capture using tcpdump but gave up on that. Under this load we
> are producing that much data that we’re not fast enough to capture it. As a
> result, the dumped data that we have contains only a subset of all frames
> which makes it quite unusable. So we switched to jetty client logs as an
> alternative.
>
>
>
> From how I understand the http spec for chunked transfer encoding, the
> stream should be ended with
>
>
>
> last-chunk = 1*("0") [ chunk-extension ] CRLF
>
>
>
> I don’t understand how that data can have come. So why is the client
> deciding that the stream is successfu
Re: [jetty-users] EXTERNAL: Re: jetty client delivers incomplete response without exception?
at's why we would need some evidence in the form of DEBUG logs. > > > We do run in k8s, so there are some hops (k8s services) in between the > jetty client and the jetty web server. I have no idea if these can also > play a role here. > > It could. We don't have a particularly good experience with k8s, although > it seems more stable with TCP than with UDP. > Again, no way to tell unless there is evidence (although this would > require network traces to be sure). > > -- > Simone Bordet > > > https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcometd.org%2Fdata=05%7C01%7Cbert.robben%40fisglobal.com%7C6b9a6bc7a77240137ccf08da22268dbd%7Ce3ff91d834c84b15a0b418910a6ac575%7C0%7C0%7C637859846664537035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=oE1wL9ZCbx2Iu1eMnfPUsWWvmdpMPONzKC5cAs5vZFA%3Dreserved=0 > > https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebtide.com%2Fdata=05%7C01%7Cbert.robben%40fisglobal.com%7C6b9a6bc7a77240137ccf08da22268dbd%7Ce3ff91d834c84b15a0b418910a6ac575%7C0%7C0%7C637859846664537035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=OxP8lJHv%2BXNoGW%2BV3DMEVzAnO%2BXglP9ZnvbtzBSWZz4%3Dreserved=0 > Developer advice, training, services and support from the Jetty & CometD > experts. > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete the > message and all copies; (ii) do not disclose, distribute or use the message > in any manner; and (iii) notify the sender immediately. In addition, please > be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] class not found for HandlerContainer
; jetty-users mailing list >> jetty-users@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > > ___ > jetty-users mailing listjetty-us...@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > > > > <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> > Virus-free. > www.avg.com > <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> > <#m_98795931928853_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Solr admin UI redirecting root path requests to http instead of https
Shawn, You should be able to add --module=http-forwarded to the command line to enable the ForwardedRequestCustomizer module. You should be able to add jetty.httpConfig.relativeRedirectAllowed=true to the command line to configure relative redirection. However, typically jetty start.jar likes to have persistent configuration for modules so that you can configure them in files. If you manually did: java -server -Djetty.home=/opt/solr/server -jar start.jar --add-module=server,http,gzip,http-forwarded then that should create a start.d directory with server.ini (and http.ini and http-forwarded.ini etc.) which you can edit to configure the server. cheers On Wed, 25 May 2022 at 12:03, Shawn Heisey wrote: > On 5/24/2022 4:34 PM, Greg Wilkins wrote: > > To turn on relative redirects, you need to set the property > > `jetty.httpConfig.relativeRedirectAllowed=true`, which can be done on > > the command line or better yet in the server.ini file. > > There is no server.ini file in a Solr install. How would I configure > that? We certainly could define a sysprop on the commandline, we > already do it for other things, but I would prefer a way to do it > through configuration rather than commandline parameters. The full > command that the script uses to start Solr is already quite long. This > is from a stock install of version 8.11.1: > > java -server -Xms512m -Xmx512m -XX:+UseG1GC -XX:+PerfDisableSharedMem > -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=250 -XX:+UseLargePages > -XX:+AlwaysPreTouch -XX:+ExplicitGCInvokesConcurrent > -Xlog:gc*:file=/var/solr/logs/solr_gc.log:time,uptime:filecount=9,filesize=20M > > -Dsolr.jetty.inetaccess.includes= -Dsolr.jetty.inetaccess.excludes= > -Dsolr.log.dir=/var/solr/logs -Djetty.port=8981 -DSTOP.PORT=7981 > -DSTOP.KEY=solrrocks -Dhost=127.0.0.1 -Duser.timezone=UTC > -XX:-OmitStackTraceInFastThrow > -XX:OnOutOfMemoryError=/opt/solr/bin/oom_solr.sh 8981 /var/solr/logs > -Djetty.home=/opt/solr/server -Dsolr.solr.home=/var/solr/data > -Dsolr.data.home= -Dsolr.install.dir=/opt/solr > -Dsolr.default.confdir=/opt/solr/server/solr/configsets/_default/conf > -Dlog4j.configurationFile=/var/solr/log4j2.xml -Xss256k > -Dsolr.log.muteconsole -jar start.jar --module=http --module=gzip > > Would you expect configuring ForwardedRequestCustomizer in our provided > jetty.xml (or one of the other xml configs when using SSL) to cause > problems? If I understand what it does correctly, I would not expect it > to cause problems for users who do not have a proxy, but I haven't > looked at the code and I am hoping that someone here knows enough about > it that they can answer that question. > > I am inclined right now to uncomment the ForwardedRequestCustomizer > section in our xml configs for our next release, if someone can tell me > that it would be a safe thing to do. I've done some minimal testing and > it did not appear to cause any issues. But it certainly was not an > extensive test. Maybe I can find a co-conspirator with a large > development or testing SolrCloud cluster that would be willing to try it > out. > > Thanks, > Shawn > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Solr admin UI redirecting root path requests to http instead of https
Shawn, I think you may have a solution now, but I'll just answer any outstanding questions just in case. To turn on relative redirects, you need to set the property `jetty.httpConfig.relativeRedirectAllowed=true`, which can be done on the command line or better yet in the server.ini file. The example you sent without a proxy is exactly correct behaviour as the Host header sent is used for the non relative redirection. As you have discovered, either the Host header must be the original from the client OR the ForwardedRequestCustomizer must be used to pass over the same information. So I think it is worthwhile to correctly configure your proxy anyway, as that reduces the possibility of anything else leaking your internal IP addresses. and then configure relative redirects anyway so you have defence in depth. cheers On Wed, 25 May 2022 at 02:31, Shawn Heisey wrote: > On 5/24/22 02:03, Greg Wilkins wrote: > > To say more, we'd need to see the headers of the request arriving at > > the proxy and then arriving at jetty but my money is on their > > proxy being configured to rewrite the host header. > > I was able to duplicate the issue, and I did not have haproxy configured > to do any kind of rewriting. > > This is what I get with a verbose curl: > > https://paste.elyograg.org/view/e95b70a0 > > This is what haproxy logged for that request, showing a 302 response: > > May 24 10:01:41 - haproxy[299524] 192.168.217.199:59602 > [24/May/2022:10:01:41.656] solr~ be-solr/g8981 0/0/0/1/1 302 105 - - > --NI 1/1/0/0/0 0/0 "GET https://solr.elyograg.org:8983/ HTTP/2.0" > > Where would I do HttpConfiguration.setRelativeRedirectAllowed(true)? > That looks like Java code, and Jetty is not embedded. This is the > jetty.xml in Solr 8.x: > > > https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=blob_plain;f=solr/server/etc/jetty.xml;h=e2f4ab095984aac27185a9879964862f9ba35d4d;hb=refs/heads/branch_8_11 > > I'm still digesting Uwe's reply. To answer his question: The proxy is > https, Solr is http. > > The relevant parts of my haproxy config can be found at the link below. > The commented lines in the frontend are how I worked around the issue in > haproxy -- handling root path redirect in haproxy rather than letting it > through to Solr: > > https://paste.elyograg.org/view/b3b413c3 > > Thanks, > Shawn > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Solr admin UI redirecting root path requests to http instead of https
Shawn,
Have you tried configuring
HttpConfiguration.setRelativeRedirectAllowed(true) ?
This should stop Jetty trying to make a relative redirect into an absolute
one and perhaps using the wrong authority.
However, even without this, the server should get the authority correct if
the proxy is being well behaved. Some proxies rewrite the Host header,
which entirely defeats the purpose of the Host header (to tell the server
what authority the original client used), so you can look at the
configuration of your proxy.
Alternatively, it could be that there is no authority at all? ie no host
header and a HTTP/1.0 request?
To say more, we'd need to see the headers of the request arriving at the
proxy and then arriving at jetty but my money is on their proxy being
configured to rewrite the host header.
cheers
PS. If they really can't fix their proxy, there are ways that we can force
jetty to use a specific authority even when the client doesn't give one
or just use relative redirects.
On Tue, 24 May 2022 at 14:52, Shawn Heisey wrote:
> I'm with the Solr project. Solr runs in Jetty. It is not embedded, the
> startup script runs start.jar.
>
> I'm trying to help one of our users with a problem. They have a proxy
> server handling TLS, Solr listens without encryption.
>
> Here's the bug report on Solr:
>
> https://issues.apache.org/jira/browse/SOLR-16200/
>
> If they access the admin UI via the proxy server using https on the
> /solr URL path, where the webapp lives, everything's fine. All links
> stay https even though Solr is listening without encryption. But if
> they access the root URL with https, Jetty is redirecting them to a URL
> that is hardcoded as http://server:port/solr/ instead of preserving the
> https:// that was used to access it, which doesn't work, because the
> proxy is configured with TLS. I have reproduced the problem. I found a
> way to work around the issue with my proxy server, but it would be
> really nice if that was not required.
>
> Is there any way in the jetty config to have it preserve the URL scheme
> when it redirects? If it were to redirect to a relative path of /solr
> instead of an absolute URL that contains http:// that would fix it.
>
> What information do I need to provide to help troubleshoot and find a fix?
>
> Thanks,
> Shawn
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
--
Greg Wilkins CTO http://webtide.com
//
//
// Copyright (c) 1995-2022 Mort Bay Consulting Pty Ltd and others.
//
// This program and the accompanying materials are made available under the
// terms of the Eclipse Public License v. 2.0 which is available at
// https://www.eclipse.org/legal/epl-2.0, or the Apache License, Version 2.0
// which is available at https://www.apache.org/licenses/LICENSE-2.0.
//
// SPDX-License-Identifier: EPL-2.0 OR Apache-2.0
//
//
package org.eclipse.jetty.server;
import java.io.IOException;
import java.net.SocketAddress;
import java.util.List;
import java.util.Set;
import java.util.concurrent.CopyOnWriteArrayList;
import org.eclipse.jetty.http.CookieCompliance;
import org.eclipse.jetty.http.HttpCompliance;
import org.eclipse.jetty.http.HttpMethod;
import org.eclipse.jetty.http.HttpScheme;
import org.eclipse.jetty.http.UriCompliance;
import org.eclipse.jetty.util.HostPort;
import org.eclipse.jetty.util.Index;
import org.eclipse.jetty.util.Jetty;
import org.eclipse.jetty.util.annotation.ManagedAttribute;
import org.eclipse.jetty.util.annotation.ManagedObject;
import org.eclipse.jetty.util.component.Dumpable;
import org.eclipse.jetty.util.component.DumpableCollection;
/**
* HTTP Configuration.
* This class is a holder of HTTP configuration for use by the
* {@link HttpChannel} class. Typically an HTTPConfiguration instance
* is instantiated and passed to a {@link ConnectionFactory} that can
* create HTTP channels (e.g. HTTP, AJP or FCGI).
* The configuration held by this class is not for the wire protocol,
* but for the interpretation and handling of HTTP requests that could
* be transported by a variety of protocols.
*
*/
@ManagedObject("HTTP Configuration")
public class HttpConfiguration implements Dumpable
{
public static final String SERVER_VERSION = "Jetty(" + Jetty.VERSION + ")";
private final List _customizers = new CopyOnWriteArrayList<>();
private final Index.Mutable _formEncodedMethods = new Index.Builder()
.caseSensitive(false)
.mutable()
.build();
private int _outputBufferSize = 32 * 1024;
private int _outputAggregationSize = _outputBufferSiz
Re: [jetty-users] Can't edit files, locked by server
Use Linux Well if you insist on using insecure clunky operating systems like Windows, then what you need to do is to stop Jetty keeping any file references at all open. So stopping file mapped buffer usage is a good step, but you probably also need to set up a zero sized static content cache. setting param maxCacheSize to 0 should help.Tell us how that goes. cheers On Sat, 26 Feb 2022 at 16:16, John English wrote: > I have an ancient Jetty 8.1.4 plus Derby plus JDK 1.7 plus portable > Notepad++ setup which I used to give to students about a decade ago as a > self-contained distro in a zipfile. (Yes, I know I should update the > Jetty version, not to mention the Derby, Java and Notepad++ versions, > but please bear with me anyway.) > > I now want to give a new group of students the same setup, but my > problem is that when a file is opened via the server, it's locked and > can't be edited. I have the following in my jetty.xml: > > > Default > > org.eclipse.jetty.servlet.DefaultServlet > >useFileMappedBuffer >false > > 0 > > > > jsp > org.apache.jasper.servlet.JspServlet > >logVerbosityLevel >DEBUG > > >compilerSourceVM >1.7 > > >compilerTargetVM >1.7 > > >fork >false > > >useFileMappedBuffer >false > > >keepgenerated >true > > 0 > > > I thought that setting "useFileMappedBuffer" to "false" was the way to > avoid file locking, but after all these years I seem to be > misremembering. What do I need to do to allow files to be edited after > the server has accessed them? > > Thanks, > -- > John English > > -- > This email has been checked for viruses by AVG. > https://www.avg.com > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 9.4.44 Classloader visibility issue
Jetty strives very hard to stop classloader pollution between contexts. But then applications can often work very hard to defeat that effort... eg if they pass an instance of an object via attributes of a cross context dispatch. Other issues can be caused if classes are put on the server path and exposed to individual contexts. So Jetty itself should definitely not reuse classloaders. We go to great efforts to flush out all loaded objects when a context is stopped, just to stop the memory leak issues. We definitely don't deliberately pass objects or loaders between contexts. So to work out what is going on, we need a better picture of your classloaders, both for the server and all the contexts (a jetty server dump would help with that). But we also need to know if there is any cross context dispatching going on, or any other communication between contexts? regards On Tue, 15 Feb 2022 at 00:28, Michael Klenk wrote: > Hi Community, > > > I've been experiencing weird classloading issues due to redeployment of > a single WAR Application containing latest Jersey Framework. > > In the current setup I'm using Jetty 9.4.44 as Application Container to > host webapplications on a Linux host. In the past I've restarted the > Jetty process on Linux when I've deployed new applications. Recently > I've tried to just redeploy the WAR file to the server and was getting > ClassNotFound Exceptions from the Classloader. A deeper analysis > showed, that the Jersey class was still loaded from the former > classloader instance of WebAppClassloader from a different context, > which I expected to be deleted with the webapplication on unloading the > context and redeploying the software without restarting the Jetty > Process. It happened even if the former application was removed and the > deployment of the WAR file happened minutes later in a second step. > > Is this a known issue with Jetty, reusing unused classloader instances? > Or is it a Bug with Jersey framework or Jetty Classloader isolation? How > could an application force Jetty to share multiple WebAppClassLoader > instances inside of one single context. > > Thank you in advance > > > Michael > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Deploying Multiple Webapps to a Jetty Server
Patrick, If you want to start applications individually and have separate log files, then you probably need to have different jetty-bases for them and different server ports. Alternately, you can hot deploy multiple webapps to a single running server. Or if you really need fine grained control, you could write your own deployer variation that start/stops the applications as you need. On Thu, 16 Dec 2021 at 03:15, Patrick Buchheit wrote: > I'm getting ready to deploy an application with jetty 9.4 but there are > some configuration aspects I'm struggling to wrap my head around. How do I > layout my files in JETTY_BASE to allow the startup and shutdown of > individual applications if there are multiple wars in webapps? Is there a > command line option to specify which applications to start? How do I > configure the logging to have a separate log file for each application? > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Question about ErrorHandler
It depends a little bit on how the error was generated in the first place? Is the request attribute "javax.servlet.error.servlet_name" set? if so, then you can use that name to lookup the servlet instance directly on the servlet handler. But your request attribute technique is probably fine as well. regards ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] memory leak in jetty monitor ?
Ivan,
Wow, jetty-7 isn't just old, it is ancient!
It could be the problem found/fixed in 2015 :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=484822
But jetty-monitor isn't even part of Jetty any more.
So sorry, we can't offer you much support on this one. But the beauty of
open source is that you are free to find/fix the issue yourself. Do tell
us how you go.
cheers
On Sat, 11 Sept 2021 at 04:04, Ivan 163 wrote:
> Hi,
> We are using jetty-monitor to print the thread usage, which following
> the configurations on the link [1]. After running the jetty server for a
> while, we found that tons of EventState instances, which were held by the
> _states variable in the AttrEventTrigger. We are trying to dive into the
> monitor the codes, it seems that the issue is that, the thread status
> retrieved from the mbean server are saved in the _states map in the match
> method, but there is no remove action is invoked. So is it possible an
> issue here ?
>Although the jetty version we used is an very old one 7.6.7, it seems
> that no code is changed in the lastest 9.x version.
>
> *public* *final* *boolean* match(*long* timestamp)
>
> *throws* Exception
>
> {
>
> MBeanServerConnection serverConnection = JMXMonitor.
> getServiceConnection();
>
>
>
> TYPE value = *null*;
>
> *try*
>
> {
>
> *int* pos = *this*._attributeName.indexOf('.');
>
> *if* (pos < 0) {
>
> value = (Comparable)serverConnection.getAttribute(*this*.
> _nameObject, *this*._attributeName);
>
> } *else* {
>
> value = getValue((CompositeData)serverConnection.getAttribute(
> *this*._nameObject, *this*._attributeName.substring(0, pos)), *this*.
> _attributeName
>
> .substring(pos + 1));
>
> }
>
> }
>
> *catch* (Exception ex)
>
> {
>
> LOG.debug(ex);
>
> }
>
> *boolean* result = *false*;
>
> *if* (value != *null*)
>
> {
>
> result = match(value);
>
> *if* ((result) || (getSaveAll())) {
>
> *this*._states.put(Long.valueOf(timestamp), *new* EventState(
>
> getID(), getNameString(), value));
>
> }
>
> }
>
> *return* result;
>
> }
>
> [1]
> https://wiki.eclipse.org/Jetty/Reference/jetty-monitor#Starting_the_In-process_Monitor
>
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
--
Greg Wilkins CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Concurrent timeout exception
On Tue, 20 Jul 2021 at 18:51, John English wrote: > On 20/07/2021 02:26, Greg Wilkins wrote: > > > > It means that a request arrived and your app was trying to extract > > parameters from the body of the request, but blocked as the full body > > had not yet arrived. After 30 seconds the data still had not arrived so > > the read timed out. > > OK. So, this is down to a network problem rather than a webapp error? > And presumably the user can just reload to resubmit the request and > thereby recover from it? If so, I will be able to change the webapp to > report it to the user as a "normal" error rather than treating it as an > unexpected error (which sends me an alert email, saves a stack trace in > the log and so on). > Typically such timeouts can occur for a huge number of reasons: - user suspended their laptop - user on train that went into a tunnel - network failure Most of these means that the user is out of contact so you can't tell them anything about it unless by user you mean the person reading the log file? Typically we suppress such IOExceptions logging to be at debug level because they can occur for some many innocuous reasons. -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Concurrent timeout exception
It means that a request arrived and your app was trying to extract parameters from the body of the request, but blocked as the full body had not yet arrived. After 30 seconds the data still had not arrived so the read timed out. On Mon, 19 Jul 2021 at 18:03, John English wrote: > I just saw the following error, which happened to a user yesterday > afternoon and was emailed to me automatically: > > org.eclipse.jetty.io.RuntimeIOException: java.io.IOException: > java.util.concurrent.TimeoutException: Idle timeout expired: 30001/3 ms > at org.eclipse.jetty.server.Request.extractFormParameters(Request.java:587) > at > org.eclipse.jetty.server.Request.extractContentParameters(Request.java:531) > at org.eclipse.jetty.server.Request.getParameters(Request.java:435) > at org.eclipse.jetty.server.Request.getParameter(Request.java:1075) > at ... > > Can anyone tell me what this means and what might be causing it? (I'm > using Jetty 9.4.41.) > > -- > John English > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Question regd jetty ssl configuration.
John, Not secure at all, nor is it intended to be. The issue is that if the server is to be started automatically without the need to enter a passphrase, then encryption cannot be used since the server needs to provide the keystore passwords at runtime.OBF is simply a way to put the pass phrases into a configuration file so that a casual observer looking over your shoulder cannot easily remember the configured passwords.MD5 cannot be used at all in this situation (it is provided for checking things like BASIC authentication where a credential is sent over "the wire" but we want to avoid storing such credentials on the server, so we check the MD5 of the provided credential with the stored MD5). BCrypt would not help, as it requires a passphrase.If we put that passphrase in a config file, then it's just the same problem... how to protect the passphrase needed to recover the password needed to recover the private key Ultimately if a server is to start automatically, without human intervention, then you need to rely on the OS security to keep a configuration file secure. cheers On Fri, 16 Jul 2021 at 01:52, John English wrote: > On 15/07/2021 18:27, Joakim Erdfelt wrote: > > The `MD5:` format Credential / Password is what's known as a 1-way hash > > (this is not encryption) > > You can take a password and generate a MD5. > > Then later, when a password is provided, you can run the hash again and > > compare the resulting MD5 to know if the password that was provided is a > > match. > > Ouch. MD5? Not terribly secure. I prefer BCrypt. > > -- > John English > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jakarta REST API Query
Aniruddha, sorry, but I have no knowledge of the s3 APIs etc. All I'd say is that from an async API design point of view, there should always be some mechanism to allow you to associate an async response received with the request that you sent. There has got to be a way to either give some ID or get some ID to the request to Flask is obtainable from the results of the POST. On Mon, 28 Jun 2021 at 11:52, Aniruddha Tekade via jetty-users < jetty-users@eclipse.org> wrote: > Bill, > > Flask server only executes the lambda function (transforming the data -- > ex. "my experiment with s3 object lambda".upper()) in python and then > returns (or calls with) the transformed data in the body of response to > write_get_object_response() defined with Java Server. > Best, > Aniruddha > > > ᐧ > > On Sun, Jun 27, 2021 at 6:33 PM Bill Ross wrote: > >> If the Flask server doesn't do synchronous responses, that would explain >> my confusion. If it does, you may be misunderstanding me. >> >> Bill >> On 6/27/21 5:59 PM, Aniruddha Tekade via jetty-users wrote: >> >> Yes, I can remove the flask server and use Jython instead to make this >> run in the same Java server. >> But since I am trying to reproduce what AWS does with S3 Object Lambda >> <https://docs.aws.amazon.com/AmazonS3/latest/API/API_WriteGetObjectResponse.html> >> - >> >> *WriteGetObjectResponse* >>> >>> <https://docs.aws.amazon.com/AmazonS3/latest/API/s3-api.pdf#API_WriteGetObjectResponse>Passes >>> transformed objects to a GetObject operation when using Object Lambda >>> Access Points. For information about Object Lambda Access Points, see >>> Transforming >>> objects with Object Lambda Access Points >>> <https://docs.aws.amazon.com/AmazonS3/latest/userguide/transforming-objects.html> >>> in >>> the *Amazon S3 User Guide*. >>> This operation supports metadata that can be returned by GetObject >>> <https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html>, >>> in addition to RequestRoute, RequestToken, StatusCode, ErrorCode, and >>> ErrorMessage. The GetObject response metadata is supported so that the >>> WriteGetObjectResponse caller, typically an AWS Lambda function, can >>> provide the same metadata when it internally invokes GetObject. When >>> WriteGetObjectResponse is called by a customer-owned Lambda function, >>> the metadata returned to the end user GetObject call might differ from >>> what Amazon S3 would normally return. >> >> I am trying to find a workaround/mechanism to get this to work. >> >> Best, >> Aniruddha >> >> >> ᐧ >> >> On Sun, Jun 27, 2021 at 5:52 PM Bill Ross wrote: >> >>> Speaking from general server dev going back to the 90's, but w/o Amazon >>> or Flask, so may not apply: >>> >>> >>>- Jetty server now forwards the request to a Python Flask server >>>which has the lambda function by passing object data to it >>>- Lambda function code perform the transformation on the object and >>>POST it back to Jetty server (which is a different API called >>>writeGetObjectResponse) >>> >>> It seems the original GET should be waiting on a synchronous call to the >>> Flask server (after the sync GET to HS/HSC), and respond by forwarding the >>> response? >>> >>> >>> >>> -- >>> Phobrain.com >>> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/jetty-users >>> >> >> _______ >> jetty-users mailing listjetty-us...@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> >> -- >> Phobrain.com >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jakarta REST API Query
I'm a bit confused by your diagrams and descriptions. Perhaps a simple interaction diagram would help? If it is just Client ---GET--> Jetty --GET--> Flask, then I'm not seeing the problem. Just async wait for the response from Flask. But one of your diagrams/descriptions suggests that the sequence is: 1. Jetty receives GET request from client 2. Jetty sends GET request to Flask which competes 3. Jetty receives POST request from Flask, which needs to be matched to original GET from client 4. Jetty sends response to original GET request Is this the case? If so, then it's a matter for the API talking to Flask, as you must be able to tunnel some id or other that will allow you to do the lookup at step 3. Eitherway, a clearer description of the interaction and the issues you have would help. On Mon, 28 Jun 2021 at 11:00, Aniruddha Tekade via jetty-users < jetty-users@eclipse.org> wrote: > Yes, I can remove the flask server and use Jython instead to make this run > in the same Java server. > But since I am trying to reproduce what AWS does with S3 Object Lambda > <https://docs.aws.amazon.com/AmazonS3/latest/API/API_WriteGetObjectResponse.html> > - > > *WriteGetObjectResponse* >> >> <https://docs.aws.amazon.com/AmazonS3/latest/API/s3-api.pdf#API_WriteGetObjectResponse>Passes >> transformed objects to a GetObject operation when using Object Lambda >> Access Points. For information about Object Lambda Access Points, see >> Transforming >> objects with Object Lambda Access Points >> <https://docs.aws.amazon.com/AmazonS3/latest/userguide/transforming-objects.html> >> in >> the *Amazon S3 User Guide*. >> This operation supports metadata that can be returned by GetObject >> <https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html>, in >> addition to RequestRoute, RequestToken, StatusCode, ErrorCode, and >> ErrorMessage. The GetObject response metadata is supported so that the >> WriteGetObjectResponse caller, typically an AWS Lambda function, can >> provide the same metadata when it internally invokes GetObject. When >> WriteGetObjectResponse is called by a customer-owned Lambda function, >> the metadata returned to the end user GetObject call might differ from >> what Amazon S3 would normally return. > > I am trying to find a workaround/mechanism to get this to work. > > Best, > Aniruddha > > > ᐧ > > On Sun, Jun 27, 2021 at 5:52 PM Bill Ross wrote: > >> Speaking from general server dev going back to the 90's, but w/o Amazon >> or Flask, so may not apply: >> >> >>- Jetty server now forwards the request to a Python Flask server >>which has the lambda function by passing object data to it >>- Lambda function code perform the transformation on the object and >>POST it back to Jetty server (which is a different API called >>writeGetObjectResponse) >> >> It seems the original GET should be waiting on a synchronous call to the >> Flask server (after the sync GET to HS/HSC), and respond by forwarding the >> response? >> >> >> >> -- >> Phobrain.com >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Limiting connections
Once shutdownOutput() has been done, the connection will still need to be fillInterested to seek the close from the other end, thus it's idle timeout will still apply. So either the close will arrive from the other end, or idletimeout happens and then you should just close the endpoint. On Tue, 25 May 2021 at 02:09, Josh Spiegel wrote: > Thanks for the response Greg. After writing the response and calling > shutdownOutput(), how do I set a forceful close timeout? > > Thanks, > Josh > > On Thu, May 20, 2021 at 3:09 PM Greg Wilkins wrote: > >> There is nothing preventing you accepting a connection and then >> immediately sending an error response assuming a request is coming, and >> half closing the connection. You can then give it a Connection class that >> just consumes any characters received up to a low limit or short timeout. >> >> >> >> On Fri, 21 May 2021, 05:02 Josh Spiegel, wrote: >> >>> Hi, >>> >>> I'm using Jetty with a custom Connection/ConnectionFactory. >>> >>> I want to impose a connection limit and I don't want to abruptly close >>> the connection without providing an error to the client. Rather, I'd like >>> to send an error message and then close the connection. But I can't send >>> the error response until I have received the first request. I don't have >>> control over when the client sends the first request but it would typically >>> be shortly after the connection is established. >>> >>> What is the best way to do this? >>> >>> One idea I have is: >>> (1) when the connection is created, schedule a task that will come back >>> and close it within some short period (a few seconds) >>> (2) if within that period, I get a request, send the error and then >>> close the connection on the endPoint() write callback. >>> >>> Thanks, >>> Josh >>> >>> >>> >>> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/jetty-users >>> >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] File upload fails on live system, works on development system
John, can you get a TCPdump (aka wireshark dump) of a large file upload? The exception indicates that the client is closing the connection before the entire content is uploaded. So it would be good to know if that is done with a RST or a FIN to see if there is a reason for that. On Sun, 23 May 2021 at 19:02, John English wrote: > On 22/05/2021 11:07, John English wrote: > > On 21/05/2021 16:55, Simone Bordet wrote: > >> Multipart works on dev environment? > >> If so, then it's some configuration difference between the two. > > > > Yes. Compared all files between server and dev kit -- no differences. > > Went onto server machine and connected via localhost -- files upload > > successfully. > > So now I'm trawling through the server's iptables logs and trying to > > find out if anyone changed the firewall rules... :( > > Some more data points: it isn't the firewall. Connecting via localhost > is OK, connecting via external domain name or IP address is not. Small > files (~50k) load OK, larger files (~250k) fail as follows: > > org.eclipse.jetty.io.RuntimeIOException: > org.eclipse.jetty.io.EofException: Early EOF > at > org.eclipse.jetty.server.Request.extractContentParameters(Request.java:548) > at org.eclipse.jetty.server.Request.getParameters(Request.java:435) > at > org.eclipse.jetty.server.Request.getParameterMap(Request.java:1084) > > (I made a couple of changes to try and get more info out of the system.) > > The logfile contains entries like this: > > - - [23/May/2021:08:50:37 +] "POST /edit?course=XY101 HTTP/1.1" 500 0 > > It was previously a 302 error, now a 500, and there is no source IP > being recorded for the request. > > It presumably isn't Jetty-related, since it works from localhost, but > perhaps someone with more knowledge of networking nuts & bolts than me > can suggest some reason why this might be happening? > > Thanks, > -- > John English > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Limiting connections
There is nothing preventing you accepting a connection and then immediately sending an error response assuming a request is coming, and half closing the connection. You can then give it a Connection class that just consumes any characters received up to a low limit or short timeout. On Fri, 21 May 2021, 05:02 Josh Spiegel, wrote: > Hi, > > I'm using Jetty with a custom Connection/ConnectionFactory. > > I want to impose a connection limit and I don't want to abruptly close the > connection without providing an error to the client. Rather, I'd like to > send an error message and then close the connection. But I can't send the > error response until I have received the first request. I don't have > control over when the client sends the first request but it would typically > be shortly after the connection is established. > > What is the best way to do this? > > One idea I have is: > (1) when the connection is created, schedule a task that will come back > and close it within some short period (a few seconds) > (2) if within that period, I get a request, send the error and then close > the connection on the endPoint() write callback. > > Thanks, > Josh > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] [jetty-dev] Jetty 9.4.* p2 repos
Thanks! On Thu, 22 Apr 2021 at 04:16, Kit Lo wrote: > I just started helping Eclipse Project's release engineering. I saw the > post about missing Jetty 9.4.* p2 repos. I wanted to help. > > I fixed up the old "jetty-rt-bundles-9" job, which encountered some > problems after migrating to the new JIRO infra. I generated the following > new p2 repos: > > https://download.eclipse.org/jetty/updates/jetty-bundles-9.x/9.4.38.v20210224/ > > https://download.eclipse.org/jetty/updates/jetty-bundles-9.x/9.4.39.v20210325/ > > https://download.eclipse.org/jetty/updates/jetty-bundles-9.x/9.4.40.v20210413/ > > I did some checkings. The new p2 repos look good. However, I need the > community to verify the repos. > > Let me know if you see any problems. I will try my best to help. > > Regards, > Kit Lo > Eclipse Babel Project Lead > IBM Eclipse SDK (IES) Technical Lead and Release Manager > ___ > jetty-dev mailing list > jetty-...@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-dev > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Either OR but not Both.
Som,
Without a web.xml, the Jersey servlet is not setup to handle requests.
Without Jersey, there is nothing in Jetty to map any request to MyResource.
Unless there is something annotated or in a discovered webfragment, then
Jetty has no handler for that request and 404 is the correct response.
regards
On Mon, 5 Apr 2021 at 00:10, Som Lima wrote:
> Let me put it another way.
> If I remove web.xml why does the following code give me 404 in jetty 11 ?
>
>
> import jakarta.ws.rs.GET;
> import jakarta.ws.rs.Path;
> import jakarta.ws.rs.Produces;
> import jakarta.ws.rs.core.MediaType;
>
> /**
> * Root resource (exposed at "myresource" path)
> */
> @Path("myresource")
> public class MyResource {
>
> /**
> * Method handling HTTP GET requests. The returned object will be sent
> * to the client as "text/plain" media type.
> *
> * @return String that will be returned as a text/plain response.
> */
> @GET
> @Produces(MediaType.TEXT_PLAIN)
> public String getIt() {
> return "got, it!";
> }
> }
>
> On Sun, 4 Apr 2021, 15:03 Joakim Erdfelt, wrote:
>
>> is only used when Jetty is in charge of serving
>> static content.
>> Or said another way, when there is a request for a resource that doesn't
>> match a url-pattern that the webapp has specified, then the servlet spec
>> Default Servlet kicks in and determines static content, welcome-files, etc
>> ...
>>
>> You have jersey setup with /*, which means
>> Jersey is responsible for 100% of content served.
>> Jetty is not involved in much with that configuration.
>>
>> I don't understand this kind of configuration, Jersey usage should be
>> focused, only on REST api resources, not 100% of content, including static
>> and default servlet.
>> I would recommend that you specify jersey on a narrow focused
>> url-pattern, like `/api/*` and leave the other requests for resources to
>> Jetty (it can serve static content WAY BETTER than Jersey can).
>>
>> Joakim Erdfelt / joa...@webtide.com
>>
>>
>> On Sat, Apr 3, 2021 at 1:55 AM Som Lima wrote:
>>
>>>
>>> IF I have the web.xml then localhost:8080/myresource works fine
>>> BUT the index.jsp is not picked with localhost:8080 or
>>> http://localhost/index.jsp
>>> I got an 404.
>>> URI: /
>>> STATUS: 404
>>>
>>> IF I remove the web.xml then the index.jsp is picked up which is what is
>>> meant to happen with jetty because it's built in functionality
>>> assumes an index.jsp file is there and will pick it and publish it.
>>> But the I get a 404 with localhost:8080/myresource now.
>>> I want both index.jsp to be picked up and have the jersey functionality
>>> localhost:8080/myresource with the web.xml
>>> but I can only have one or the other.
>>>
>>>
>>> https://jakarta.ee/xml/ns/jakartaee; xmlns:xsi="
>>> http://www.w3.org/2001/XMLSchema-instance;
>>> xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
>>> https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd;
>>> version="5.0">
>>>
>>>
>>> Jersey Web Application
>>>
>>> org.glassfish.jersey.servlet.ServletContainer
>>>
>>>
>>> jersey.config.server.provider.packages
>>> com.example
>>>
>>> 1
>>>
>>>
>>> Jersey Web Application
>>> /*
>>>
>>>
>>>
>>>
>>> index.jsp
>>>
>>>
>>>
>>>
>>>
>>> import jakarta.ws.rs.GET;
>>> import jakarta.ws.rs.Path;
>>> import jakarta.ws.rs.Produces;
>>> import jakarta.ws.rs.core.MediaType;
>>>
>>> /**
>>> * Root resource (exposed at "myresource" path)
>>> */
>>> @Path("myresource")
>>> public class MyResource {
>>>
>>> /**
>>> * Method handling HTTP GET requests. The returned object will be
>>> sent
>>> * to the client as "text/plain" media type.
>>> *
>>> * @return String that will be returned as a text/plain response.
>>> */
>>> @GET
>>> @Produces(MediaType.TEXT_PLAIN)
>>> public String getIt() {
>>> return "got, it!";
>>> }
>>> }
>>>
>>>
>
Re: [jetty-users] Jsp configuration class
Som,
in 11 there is indeed no ClassList, so that part is "broken". Just delete
those lines... and tell us what your code was doing with classlist.
Note switching back and forth from 9 to 11 is difficult.
On Sat, 3 Apr 2021 at 17:59, Som Lima wrote:
> Then there is an issue with
>Configuration.ClassList classlist = Configuration.ClassList
> .setServerDefault(server);
>
> I kept changing jetty version in pom.xml from 11 to 9.
> That is the only change I made.
> I did it a number of times to satisfy myself.
> When 9 no issue but when 11 then an error reported by eclipse IDE.
>
>
> On Sat, 3 Apr 2021, 06:51 Greg Wilkins, wrote:
>
>> Som,
>>
>> Neither WebAppContext nor ServletHandlerContext are obsolete.
>>
>> However, you only need to call setConfigurations in exceptional
>> circumstances as typically it is sufficient just to put a jar on the class
>> path for any Configuration instance that it contains to be discovered and
>> added to your WebAppContext automatically.
>>
>>
>> On Sat, 3 Apr 2021 at 14:59, Som Lima wrote:
>>
>>>
>>> The use of both the WebAppContext class and ServletHandlerContext
>>> class have become obsolete in jetty 11 so the recommendation to use
>>> classlist instead of WebAppContext.setConfigurations wasn't relevant.
>>>
>>>
>>>
>>> On Fri, 26 Mar 2021, 23:40 Joakim Erdfelt, wrote:
>>>
>>>> What version of Jetty are you using?
>>>>
>>>> Joakim Erdfelt / joa...@webtide.com
>>>>
>>>>
>>>> On Fri, Mar 26, 2021 at 6:34 PM Som Lima
>>>> wrote:
>>>>
>>>>> Hi Thanks,
>>>>>
>>>>> I did try this Configuration.ClassList approach earlier but I was
>>>>> getting an error "
>>>>> Multiple markers at this line
>>>>> - ClassList cannot be resolved or is not a field
>>>>> - Configuration.ClassList cannot be resolved to a
>>>>> type
>>>>>
>>>>> I think was due to an incompatible server object.
>>>>>
>>>>> I am working in another project now
>>>>> this time I inserted the code , no eclipse IDE errors reported I
>>>>> guess the server object is compatible.
>>>>> My code looks like this but still I am missing JSP feature. Not sure
>>>>> the syntax for that.
>>>>> console error message" No JSP support. Check that JSP jars are in
>>>>> lib/jsp and that the JSP option has been specified to start."
>>>>>
>>>>>
>>>>> *I have these two dependencies in pom.xml*
>>>>>
>>>>>
>>>>> org.eclipse.jetty
>>>>> apache-jsp
>>>>> ${jetty.version}
>>>>>
>>>>>
>>>>> jstl
>>>>> jstl
>>>>> 1.2
>>>>>
>>>>>
>>>>>
>>>>> *This is what my code looks like but I don't think I have the jsp
>>>>> configuration in either variations*
>>>>>
>>>>>context.setBaseResource(Resource.newResource(webResourceBase));
>>>>> context.setConfigurations(new Configuration[]
>>>>> {
>>>>> new AnnotationConfiguration(),
>>>>> new WebInfConfiguration(),
>>>>> new WebXmlConfiguration(),
>>>>> new MetaInfConfiguration(),
>>>>> new FragmentConfiguration(),
>>>>> new EnvConfiguration(),
>>>>> new PlusConfiguration(),
>>>>> new JettyWebXmlConfiguration()
>>>>> });
>>>>>
>>>>> // === setup jetty plus ==
>>>>> Configuration.ClassList classlist = Configuration.ClassList
>>>>> .setServerDefault(server);
>>>>> classlist.addAfter(
>>>>> "org.eclipse.jetty.webapp.FragmentConfiguration",
>>>>> "org.eclipse.jetty.plus.webapp.EnvConfiguration",
>>>>> "org.eclipse.jetty.plus.webapp.PlusConfiguration");
>>>>>
>>>>> classlist.addBefore("org.eclipse.jetty.webapp.JettyWebXmlConfiguration",
>>>>> "org.eclipse.jetty.annotations.AnnotationConfiguration");
>>>>>
>>
Re: [jetty-users] Jsp configuration class
quot;);
>>>>
>>>> // Add Annotation Scanning Support
>>>>
>>>> classlist.addBefore("org.eclipse.jetty.webapp.JettyWebXmlConfiguration",
>>>> "org.eclipse.jetty.annotations.AnnotationConfiguration");
>>>>
>>>> Leave the existing Configurations in place, don't overwrite/replace the
>>>> entire list like you are doing.
>>>> There is no need to configure the WebAppContext directly.
>>>>
>>>> Joakim Erdfelt / joa...@webtide.com
>>>>
>>>>
>>>> On Fri, Mar 26, 2021 at 4:42 PM Som Lima
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> There appears to be a number of ways to configure annotations, jsp
>>>>> support programmatically in the jetty embedded. i.e.
>>>>> Configuration.ClassList.
>>>>>
>>>>> I have gone for this implementation.
>>>>> Is there a one liner new class I can insert in this code to add for
>>>>> JSP functionality followed by corresponding libraries in the pom.xml ?
>>>>>
>>>>> context.setConfigurations(new Configuration[]
>>>>> {
>>>>> new AnnotationConfiguration(),
>>>>> new WebInfConfiguration(),
>>>>> new WebXmlConfiguration(),
>>>>> new MetaInfConfiguration(),
>>>>> new FragmentConfiguration(),
>>>>> new EnvConfiguration(),
>>>>> new PlusConfiguration(),
>>>>> new JettyWebXmlConfiguration()
>>>>> });
>>>>> <http://www.backbutton.co.uk/>
>>>>> Regards
>>>>>
>>>>>
>>>>> ___
>>>>> jetty-users mailing list
>>>>> jetty-users@eclipse.org
>>>>> To unsubscribe from this list, visit
>>>>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>>>>
>>>> ___
>>>> jetty-users mailing list
>>>> jetty-users@eclipse.org
>>>> To unsubscribe from this list, visit
>>>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>>>
>>> ___
>>> jetty-users mailing list
>>> jetty-users@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
--
Greg Wilkins CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] WebAppContext Jetty 11
In jetty 11 such features are auto configuring. You just need to add the jar to the classpath and the feature will be discovered and added to the webapp. So just put jetty-annotation jar on the classpath On Sat, 3 Apr 2021, 06:32 Som Lima, wrote: > Hi, > > I am looking for code showing how to configure embedded jetty to add > features like annotations jsf etc. > > to the WebAppContext class in particular rather than adding features > using the ServletHandlerContext. > > for jetty version 11. > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jsp configuration class
Som,
we are not responsible for the Heroku archetypes, but that main class looks
reasonable.
With jetty-11, all that is necessary to enable JSPs is to put the jetty-jsp
jar on the classpath and it will be discovered and available to the webapp.
On Fri, 2 Apr 2021 at 13:08, Som Lima wrote:
> Hi,
>
> using Heroku archetype jetty 11,
> It appeared the jetty configurations may be different
> when running mvn jetty:run compared to running
> embedded jetty using the main class. (below)
> That is to say I would need to add further programmatic configuration to
> the embedded jetty.
>
> /**
> * This class launches the web application in an embedded Jetty container.
> * This is the entry point to your application. The Java
> * command that is used for launching should fire this main method.
> */
> public class Main {
>
> public static void main(String[] args) throws Exception{
> // The port that we should run on can be set into an environment
> variable
> // Look for that variable and default to 8080 if it isn't there.
> String webPort = System.getenv("PORT");
> if (webPort == null || webPort.isEmpty()) {
> webPort = "8080";
> }
>
> final Server server = new Server(Integer.valueOf(webPort));
> final WebAppContext root = new WebAppContext();
>
> root.setContextPath("/");
> // Parent loader priority is a class loader setting that Jetty
> accepts.
> // By default Jetty will behave like most web containers in that
> it will
> // allow your application to replace non-server libraries that are
> part of the
> // container. Setting parent loader priority to true changes this
> behavior.
> // Read more here:
> http://wiki.eclipse.org/Jetty/Reference/Jetty_Classloading
> root.setParentLoaderPriority(true);
>
> final String webappDirLocation = "src/main/webapp/";
> root.setDescriptor(webappDirLocation + "/WEB-INF/web.xml");
> root.setResourceBase(webappDirLocation);
>
> server.setHandler(root);
>
> server.start();
> server.join();
> }
> }
> <http://www.backbutton.co.uk/>
>
>
> On Thu, 1 Apr 2021, 22:14 Greg Wilkins, wrote:
>
>> Som,
>>
>> Configuration.ClassList is from Jetty-9 and is no longer needed in Jetty
>> 10 or 11.
>> The Configuraition mechanism generally requires less classpath
>> manipulation in 10 or 11, so I'd try just deleting that line. Do you know
>> why you are trying to obtain a classlist ?
>>
>> Perhaps look for the corresponding example in the jetty 11 source code?
>>
>>
>> On Tue, 30 Mar 2021 at 23:36, Som Lima wrote:
>>
>>> I was hoping for some feedback on the error.
>>>
>>> Configuration.ClassList classlist = Configuration.ClassList
>>> .setServerDefault(server);
>>>
>>> Multiple markers at this line
>>> - ClassList cannot be resolved or is not a field
>>> - Configuration.ClassList cannot be resolved to a
>>> type
>>>
>>> I think was due to an incompatible server object.
>>>
>>>
>>> Whether my guess was correct or not ?
>>>
>>>
>>>
>>> On Fri, 26 Mar 2021, 23:49 Som Lima, wrote:
>>>
>>>> Problem version
>>>>
>>>> org.apache.maven.plugins
>>>> maven-compiler-plugin
>>>> 3.8.0
>>>> true
>>>>
>>>> 11
>>>> 11
>>>>
>>>>
>>>>
>>>> 11.0.1
>>>> <http://www.backbutton.co.uk/>
>>>>
>>>>
>>>> On Fri, 26 Mar 2021, 23:45 Som Lima, wrote:
>>>>
>>>>> Now
>>>>> 9.4.35.v20201120
>>>>> on
>>>>> 11
>>>>> 11
>>>>> <http://www.backbutton.co.uk/>
>>>>>
>>>>>
>>>>> On Fri, 26 Mar 2021, 23:40 Joakim Erdfelt, wrote:
>>>>>
>>>>>> What version of Jetty are you using?
>>>>>>
>>>>>> Joakim Erdfelt / joa...@webtide.com
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 26, 2021 at 6:34 PM Som Lima
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Thanks,
>>>>>>>
>>>>>>> I did try this Configuration.ClassList approach earlier but I was
>>>>>>> getting an error &qu
Re: [jetty-users] Jsp configuration class
>>>>>
>>>>> On Fri, 26 Mar 2021, 22:19 Joakim Erdfelt, wrote:
>>>>>
>>>>>> The order of that Configuration list is very important.
>>>>>>
>>>>>> It would be better to utilize the Server level component and just add
>>>>>> the missing pieces you need.
>>>>>>
>>>>>> See:
>>>>>>
>>>>>>-
>>>>>>
>>>>>> https://github.com/eclipse/jetty.project/blob/jetty-9.4.38.v20210224/examples/embedded/src/main/java/org/eclipse/jetty/embedded/LikeJettyXml.java#L168-L177
>>>>>>-
>>>>>>
>>>>>> https://github.com/jetty-project/embedded-jetty-jsp/blob/4918be37b938fff9fada5910ca04c59d8969cc90/src/main/java/org/eclipse/jetty/demo/Main.java#L131-L136
>>>>>>
>>>>>>
>>>>>> // === setup jetty plus ==
>>>>>> Configuration.ClassList classlist =
>>>>>> Configuration.ClassList.setServerDefault(server);
>>>>>>
>>>>>> // Add JNDI support
>>>>>> classlist.addAfter(
>>>>>> "org.eclipse.jetty.webapp.FragmentConfiguration",
>>>>>> "org.eclipse.jetty.plus.webapp.EnvConfiguration",
>>>>>> "org.eclipse.jetty.plus.webapp.PlusConfiguration");
>>>>>>
>>>>>> // Add Annotation Scanning Support
>>>>>>
>>>>>> classlist.addBefore("org.eclipse.jetty.webapp.JettyWebXmlConfiguration",
>>>>>> "org.eclipse.jetty.annotations.AnnotationConfiguration");
>>>>>>
>>>>>> Leave the existing Configurations in place, don't overwrite/replace
>>>>>> the entire list like you are doing.
>>>>>> There is no need to configure the WebAppContext directly.
>>>>>>
>>>>>> Joakim Erdfelt / joa...@webtide.com
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 26, 2021 at 4:42 PM Som Lima
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> There appears to be a number of ways to configure annotations, jsp
>>>>>>> support programmatically in the jetty embedded. i.e.
>>>>>>> Configuration.ClassList.
>>>>>>>
>>>>>>> I have gone for this implementation.
>>>>>>> Is there a one liner new class I can insert in this code to add
>>>>>>> for JSP functionality followed by corresponding libraries in the
>>>>>>> pom.xml ?
>>>>>>>
>>>>>>> context.setConfigurations(new Configuration[]
>>>>>>> {
>>>>>>> new AnnotationConfiguration(),
>>>>>>> new WebInfConfiguration(),
>>>>>>> new WebXmlConfiguration(),
>>>>>>> new MetaInfConfiguration(),
>>>>>>> new FragmentConfiguration(),
>>>>>>> new EnvConfiguration(),
>>>>>>> new PlusConfiguration(),
>>>>>>> new JettyWebXmlConfiguration()
>>>>>>> });
>>>>>>> <http://www.backbutton.co.uk/>
>>>>>>> Regards
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> jetty-users mailing list
>>>>>>> jetty-users@eclipse.org
>>>>>>> To unsubscribe from this list, visit
>>>>>>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>>>>>>
>>>>>> ___
>>>>>> jetty-users mailing list
>>>>>> jetty-users@eclipse.org
>>>>>> To unsubscribe from this list, visit
>>>>>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>>>>>
>>>>> ___
>>>>> jetty-users mailing list
>>>>> jetty-users@eclipse.org
>>>>> To unsubscribe from this list, visit
>>>>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>>>>
>>>> ___
>>>> jetty-users mailing list
>>>> jetty-users@eclipse.org
>>>> To unsubscribe from this list, visit
>>>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>>>
>>> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
--
Greg Wilkins CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Fail-fast request handling best practices
Note that if you can control the client, then you can use the Expect: 100-Continue header to avoid sending the body until the headers are checked... but that doesn't work if the client is just a browser. It does seem like Nginx could do better if jetty has already send a 400 with connect:close and then closes the connection. It is wrong for nginx to say bad gateway, as that is a perfectly legal thing to do in HTTP. On Wed, 31 Mar 2021 at 18:00, Simone Bordet wrote: > Hi, > > On Wed, Mar 31, 2021 at 6:45 AM Daniel Gredler > wrote: > > > > Hi, > > > > I'm playing around with a Jetty-based API service deployed to AWS > Elastic Beanstalk in a Docker container. The setup is basically: EC2 load > balancer -> nginx reverse proxy -> Docker container running the Jetty > service. > > > > One of the API endpoints accepts large POST requests. As a safeguard, I > wanted to add a maximum request size (e.g. any request body larger than 1 > MB is rejected). I thought I'd be clever and check the Content-Length > header, if present. If the header indicates that the body is too large, I'd > reject the request immediately (HTTP 400 error), without even wasting time > reading the request body. I can imagine similar fail-fast checks on the > security side, using the Authorization HTTP request header. > > > > This Content-Length check works correctly most of the time, but > occasionally nginx reports "writev() failed (32: Broken pipe) while sending > request to upstream" and sends a HTTP 502 error upstream to the load > balancer, which duly informs the client that there was a HTTP 502 Bad > Gateway error somewhere along the line. > > > > It appears that in these instances Jetty is closing the connection after > sending back the HTTP 400 error, nginx doesn't notice and continues to try > to send the request body content to Jetty, sees at that point that the > connection is closed, and reports a less-than-friendly HTTP 502 error to > the client. > > > > So I'm wondering... is this fail-fast Content-Length header check too > clever? Is it best practice to actually always read the full request body, > and only fail once the body has been fully read, even if we have enough > information to reject the request much earlier? Or would most people just > accept the occasional 502 error? I've seen some mentions of SO_LINGER / > setSoLingerTime and setAcceptQueueSize as possible workarounds, but > SO_LINGER especially always seems to be surrounded with "here be dragons" > warnings... > > > > What's the best practice here? Should I just accept that I need to read > these useless bytes? > > Don't use SO_LINGER. > Your best option is to read all the bytes; would be best if you can do > this asynchronously. > > The problem is that by the time you close the connection from Jetty, > Nginx may not have received the whole content from the client. > So Jetty closes, then Nginx receives some more content from the > client, tries to write to Jetty, but finds the connection closed, and > reports back the 502. > > Not reading the content will just cause the TCP connection to congest > with the same results (502), so if you really want to send a clean 400 > you have to read the whole content. > > -- > Simone Bordet > > http://cometd.org > http://webtide.com > Developer advice, training, services and support > from the Jetty & CometD experts. > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] A suggestion
Hi Som, We are already making efforts to link the examples usinged in documentation with the source on github, so that the same file is used for both and there is no scope for a little bit of drift over time. This is still a work in progress and will mostly be visible in Jetty-10 and later documentations. cheers On Sun, 28 Mar 2021 at 11:59, Som Lima wrote: > Hi, > > As you know programming is very unforgiving . A semi colon or even comma > out of place and your programme will not "work". > > If you agree then please change > > source code examples found on this page > > https://www.eclipse.org/jetty/documentation/jetty-9/index.html > > to exactly match the working examples found on github. The source code > examples referring to programmatic configuration of jetty. > > https://github.com/jetty-project > > > Many people will land on the index page , > will have same issues as I encountered will likely give up and move on to > another product with a bad impression. > > Regards > > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Maven dependencies
Hi,
it should be in org.eclipse.jetty:example-jetty-embedded, however it is an
example class rather than part of jetty itself, so it is not published into
maven central.
It is a class just to work out a Path for where a war file is in our test
setup, so it is unlikely to be useful for you. Just set the Path warFile
to the path of where your war file is.
On Sat, 27 Mar 2021 at 16:44, Som Lima wrote:
> Hi ,
> Having issues finding maven dependencies for
> JettyDistribution
> ExampleUtil
>
>
> Path warFile =
> JettyDistribution.resolve("demo-base/webapps/test.war");
>
> int port = ExampleUtil.getPort(args, "jetty.http.port", 8080);
>
> any ideas ?
> Thanks
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
--
Greg Wilkins CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Fast SSL with jetty.
Luke, well we'll have to look into a JSSE wrapper for OpenSSL again, although Conscrypt has worked fine for some clients, so still worthwhile pushing them to fix any outstanding issues. Also, our priorities are influenced by our commercial support partners, so just a reminder that if there are commercial clients concerned, that sponsoring some development on an open source project is a great way to give back to the commons! I've opened https://github.com/eclipse/jetty.project/issues/6079 to track status cheers On Mon, 22 Mar 2021 at 13:08, Luke B wrote: > Hi Greg, > > Realistically I couldn't do the unix socket thing, I think it wouldn't be > considered secure enough since clear text sensitive data would be easily > available via that socket. Although even if that is not true, I think our > clients would just not be ok with anything other than encryption all the > way to jetty. > > I think it is worth doing something that lets jetty use a fast SSL lib. > Jetty is frequently going to be used with SSL, and Java's built in SSL lib > really kills Jetty's otherwise fantastic performance. > > -Luke > > On Mon, Mar 22, 2021 at 12:05 PM Greg Wilkins wrote: > >> Also I note that it appears that netty is wrapping OpenSSL as a >> SslEngine, so we could look at either doing the same or even reusing their >> wrapper (although it appears to pull in a lot of netty util and handlers). >> >> >> On Fri, 19 Mar 2021 at 12:42, Greg Wilkins wrote: >> >>> So unix sockets an option? >>> >>> On Fri, 19 Mar 2021, 09:21 Luke B, wrote: >>> >>>> Hi, >>>> >>>> From memory the difference in performance is rather large, maybe 10x or >>>> 20x. It really does make a difference to how many requests we can handle. >>>> Conscrypt takes jetty from being severely limited by the speed at which it >>>> can transfer encrypted data, to encryption adding no meaningful overhead to >>>> data transfer. >>>> >>>> -Luke >>>> >>>> >>>> On Tue, Mar 16, 2021 at 1:21 AM Simone Bordet >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> On Mon, Mar 15, 2021 at 12:50 AM Luke B >>>>> wrote: >>>>> > >>>>> > Hi, >>>>> > >>>>> > So it seems conscrypt has even more memory leaks: >>>>> > https://github.com/google/conscrypt/issues/835 >>>>> > https://github.com/google/conscrypt/issues/984 >>>>> > >>>>> > Conscrypt doesn't appear to be sufficiently reliable to be used in >>>>> production. >>>>> > >>>>> > Setting up jetty to listen only on localhost without SSL and having >>>>> an nginx (or other web server) reverse proxy to provide SSL is possible >>>>> but >>>>> unlikely something that is acceptable as encryption is required all the >>>>> way >>>>> to the java process. In this case a tcp dump would reveal passwords. >>>>> > >>>>> > Jetty, it seems, is trapped behind Java's relatively slow SSL >>>>> implementation. >>>>> >>>>> I guess the keyword here is "relatively". >>>>> >>>>> Java's SSL is slower no doubt, but perhaps it does the job? >>>>> Is the move to Conscrypt due to benchmarks (A is faster than B), but B >>>>> can handle the load just nicely? >>>>> Is the move to Conscrypt due to saving CPU/memory in the cloud to save >>>>> money? >>>>> >>>>> I'm saying that with the latest Java versions, with native support for >>>>> encryption primitives, TLS resumption, etc. maybe Java TLS does the >>>>> job for you. >>>>> Sure it's not the Ferrari you wanted, but it's a decently fast car >>>>> anyway? >>>>> >>>>> -- >>>>> Simone Bordet >>>>> >>>>> http://cometd.org >>>>> http://webtide.com >>>>> Developer advice, training, services and support >>>>> from the Jetty & CometD experts. >>>>> ___ >>>>> jetty-users mailing list >>>>> jetty-users@eclipse.org >>>>> To unsubscribe from this list, visit >>>>> https://www.eclipse.org/mailman/listinfo/jetty-users >>>>> >>>> ___ >>>> jetty-users mailing list >>>> jetty-users@eclipse.org >>>> To unsubscribe from this list, visit >>>> https://www.eclipse.org/mailman/listinfo/jetty-users >>>> >>> >> >> -- >> Greg Wilkins CTO http://webtide.com >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Fast SSL with jetty.
Also I note that it appears that netty is wrapping OpenSSL as a SslEngine, so we could look at either doing the same or even reusing their wrapper (although it appears to pull in a lot of netty util and handlers). On Fri, 19 Mar 2021 at 12:42, Greg Wilkins wrote: > So unix sockets an option? > > On Fri, 19 Mar 2021, 09:21 Luke B, wrote: > >> Hi, >> >> From memory the difference in performance is rather large, maybe 10x or >> 20x. It really does make a difference to how many requests we can handle. >> Conscrypt takes jetty from being severely limited by the speed at which it >> can transfer encrypted data, to encryption adding no meaningful overhead to >> data transfer. >> >> -Luke >> >> >> On Tue, Mar 16, 2021 at 1:21 AM Simone Bordet >> wrote: >> >>> Hi, >>> >>> On Mon, Mar 15, 2021 at 12:50 AM Luke B wrote: >>> > >>> > Hi, >>> > >>> > So it seems conscrypt has even more memory leaks: >>> > https://github.com/google/conscrypt/issues/835 >>> > https://github.com/google/conscrypt/issues/984 >>> > >>> > Conscrypt doesn't appear to be sufficiently reliable to be used in >>> production. >>> > >>> > Setting up jetty to listen only on localhost without SSL and having an >>> nginx (or other web server) reverse proxy to provide SSL is possible but >>> unlikely something that is acceptable as encryption is required all the way >>> to the java process. In this case a tcp dump would reveal passwords. >>> > >>> > Jetty, it seems, is trapped behind Java's relatively slow SSL >>> implementation. >>> >>> I guess the keyword here is "relatively". >>> >>> Java's SSL is slower no doubt, but perhaps it does the job? >>> Is the move to Conscrypt due to benchmarks (A is faster than B), but B >>> can handle the load just nicely? >>> Is the move to Conscrypt due to saving CPU/memory in the cloud to save >>> money? >>> >>> I'm saying that with the latest Java versions, with native support for >>> encryption primitives, TLS resumption, etc. maybe Java TLS does the >>> job for you. >>> Sure it's not the Ferrari you wanted, but it's a decently fast car >>> anyway? >>> >>> -- >>> Simone Bordet >>> >>> http://cometd.org >>> http://webtide.com >>> Developer advice, training, services and support >>> from the Jetty & CometD experts. >>> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/jetty-users >>> >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Fast SSL with jetty.
So unix sockets an option? On Fri, 19 Mar 2021, 09:21 Luke B, wrote: > Hi, > > From memory the difference in performance is rather large, maybe 10x or > 20x. It really does make a difference to how many requests we can handle. > Conscrypt takes jetty from being severely limited by the speed at which it > can transfer encrypted data, to encryption adding no meaningful overhead to > data transfer. > > -Luke > > > On Tue, Mar 16, 2021 at 1:21 AM Simone Bordet wrote: > >> Hi, >> >> On Mon, Mar 15, 2021 at 12:50 AM Luke B wrote: >> > >> > Hi, >> > >> > So it seems conscrypt has even more memory leaks: >> > https://github.com/google/conscrypt/issues/835 >> > https://github.com/google/conscrypt/issues/984 >> > >> > Conscrypt doesn't appear to be sufficiently reliable to be used in >> production. >> > >> > Setting up jetty to listen only on localhost without SSL and having an >> nginx (or other web server) reverse proxy to provide SSL is possible but >> unlikely something that is acceptable as encryption is required all the way >> to the java process. In this case a tcp dump would reveal passwords. >> > >> > Jetty, it seems, is trapped behind Java's relatively slow SSL >> implementation. >> >> I guess the keyword here is "relatively". >> >> Java's SSL is slower no doubt, but perhaps it does the job? >> Is the move to Conscrypt due to benchmarks (A is faster than B), but B >> can handle the load just nicely? >> Is the move to Conscrypt due to saving CPU/memory in the cloud to save >> money? >> >> I'm saying that with the latest Java versions, with native support for >> encryption primitives, TLS resumption, etc. maybe Java TLS does the >> job for you. >> Sure it's not the Ferrari you wanted, but it's a decently fast car anyway? >> >> -- >> Simone Bordet >> >> http://cometd.org >> http://webtide.com >> Developer advice, training, services and support >> from the Jetty & CometD experts. >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 10 websocket API changes
Silvio, yes the jetty websocket API has been significantly revisited in jetty-10. We believe that we have added significant improvements as a result and have been waiting for the major release to make such a breaking change. We definitely will continue to support our API going forward, due to deficiencies and complications of the JSR API. So if your use-case is not already supported, then we will definitely look to see if we can. Lachlan Roberts is the lead developer of websocket now and hopefully will get back to you with pointers to servlet based upgrade (which I'm 99% sure is supported). cheers On Mon, 15 Mar 2021 at 18:25, Silvio Bierman wrote: > Some time ago I extended our embedded Jetty (9.4.36) based server > application to support websockets using the Jetty websocket API. At this > time we want to revisit our previously successful efforts making the > application compatible with Jetty 10. But it seems the websocket API has > changed quite significantly and many of the classes in > org.eclipse.jetty.websocket.servlet and org.eclipse.jetty.websocket.api > (notably WebSocketServletFactory, WebSocketCreator, > ServletUpgradeRequest and ServletUpgradeResponse) appear to be missing > or have been moved/renamed. So now we use the websocket API it appears > porting to Jetty 10 has become much more difficult, let alone managing a > code-base that allows us to swap one in for the other. > > We picked the Jetty websocket API since it allows us to handle the > request upgrade at the Servlet level (inside the service method) while > the javax.websocket API upgrades to websockets at the context level and > is therefore of nu use to us. I hope this is still possible in the > revised Jetty websocket API but can not find any documentation about how > to rewrite 9.4.x based code to the new 10.x version. > > I can live with not being able to switch back to Jetty 9 without > recompiling. > > Can anyone give me some pointers? > > Kind regards, > > Silvio > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Fast SSL with jetty.
Luke, That memory leak appears to be on outgoing connection attempts, not incoming ones. So conscript should be fine for server side usage with that... or are you also using the client? As for options to avoid conscript, would offloaded SSL that communicates via a unix socket rather than localhost be acceptable? Currently this would use the not-really-ready-for-production JNR wrappers, but latest JVMs do have unix socket support, so it is something we may soon add support for. On Mon, 15 Mar 2021 at 01:55, Luke B wrote: > Hi Shawn, > > Unfortunately my clients want that illusion of safety and it is just > easier to give them that rather than argue with them. I really don't care > to argue this point. > > Do you have any ideas for solving the problem at hand? > > cheers, > > Luke > > On Mon, Mar 15, 2021 at 11:42 AM Shawn Heisey > wrote: > >> On 3/14/2021 5:50 PM, Luke B wrote: >> > Setting up jetty to listen only on localhost without SSL and having an >> > nginx (or other web server) reverse proxy to provide SSL is possible >> but >> > unlikely something that is acceptable as encryption is required all the >> > way to the java process. In this case a tcp dump would reveal passwords. >> >> Think about what would have to happen for somebody to get that packet >> capture. >> >> 1) If the reverse proxy is on a different machine than Jetty, one way in >> is for the attacker to have physical access to the hardware. They could >> patch a rogue machine in with two network ports and capture everything >> going over the machine's wire. A raspberry pi with a USB network dongle >> could probably be used for that -- relatively easy to hide. >> >> 2) If the attacker manages to acquire remote access and admin/root >> privileges, they could install tools on the machine (like tcpdump or >> wireshark) to capture those packets whether the two processes are on the >> same machine (using localhost) or on separate machines. >> >> If you have good physical security, the first attack is not going to >> happen. >> >> If the second attack succeeds, you've got bigger problems than a lack of >> encryption on the back end of your web services. They've got admin/root >> access, and might be able to obtain those privileges on other machines >> through software vulnerabilities. They would probably already have >> access to everything they might glean from capturing unencrypted >> packets. An example: Credentials in config files for services like >> mail, database, microservices, etc. >> >> It is my strong opinion that encrypting the connection between a >> front-end reverse proxy or load balancer and back end web services is an >> illusion of safety that comes at the expense of CPU time needed for the >> extra encryption. >> >> Anybody is welcome to disagree with me. >> >> I worked at a company that was setting up services for a very high >> profile customer. That customer wanted the back end encrypted like you >> do. We did it, but I think it was unnecessary. >> >> Thanks, >> Shawn >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] regular https and proxied htps at the same time
Paul,
You are correct that the jetty module system issetup to support only a
single instance of each type of connector.
To have your setup, you will need to at least right an XML file and perhaps
a custom module to make it easy to enable.
You need to copy/paste/edit the files:
${jetty.home}/etc/jetty-ssl.xml
${jetty.home}/etc/jetty-https.xml
${jetty.home}/etc/jetty-proxy-protocol-ssl.xml
to ${jetty.base} and call them jetty-sslB.xml, jetty-httpsB.xml
& jetty-proxy-protocol-sslB.xml. Edit them so that they refer to the id
`sslConnectorB`
You then can create a custom module in ${jetty.base}/modules/httpsB.mod
with contents like:
> [description]
> Adds alternate HTTPS Connector
> [depend]
> ssl
> [xml]
etc/jetty-sslB.xml
etc/jetty-httpsB.xml
etc/jetty-proxy-protocol-sslB.xml
You can replace `B` everywhere with something more descriptive... I tried
`2` but that is confusing with `http2`. You could also merge these files
into a single XML if you liked.
So, in summary, you need your own XML to create the second SSL connector
with the different configuration.
cheers
On Tue, 9 Mar 2021 at 02:46, Paul B. Henson wrote:
> I'm going to be running an instance of jetty in AWS. I'd like it to
> listen on the standard port 443 for internal https traffic, and then on
> port 4443 with proxy protocol enabled behind an ELB.
>
> I'm not clear how to accomplish that? It seems adding the proxy protocol
> module just turns it on on the default SSL port. I need to have jetty
> listen on the alternative port as well and have the proxy protocol only
> enabled on that one.
>
> Any guidance on the proper configuration for this would be greatly
> appreciated, thanks…
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
--
Greg Wilkins CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] java.util.concurrent.TimeoutException: Idle timeout expired
Hi John, it could just be that the client connection timed out?Could their network have failed part way through an upload? regards On Mon, 15 Feb 2021 at 16:26, John English wrote: > I'm using Jetty 9.4.30. Yesterday I saw the following error: > > org.eclipse.jetty.io.RuntimeIOException: java.io.IOException: > java.util.concurrent.TimeoutException: Idle timeout expired: 3/3 ms > at > org.eclipse.jetty.server.Request.extractFormParameters(Request.java:573) > at > org.eclipse.jetty.server.Request.extractContentParameters(Request.java:519) > at org.eclipse.jetty.server.Request.getParameters(Request.java:430) > at org.eclipse.jetty.server.Request.getParameter(Request.java:1059) > at servlets.LogProgress.doPost(LogProgress.java:75) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) > ... > > I googled this, and found that this has been reported for users of the > Apache fileupload package. Although I am using that package in other > servlets elsewhere, this did not happen in a multipart request -- it was > a normal post request submitted by a JavaScript XHR at 60 second > intervals to track changes to a form. > > About 20 other users were doing the same thing at the same time, but it > only happened for one of them. It happened once, then there was a 7 > minute gap, then four successive requests failed at 60 second intervals, > then it worked as normal from then onwards. > > I have now rewritten the fileupload code to use getParts() instead, just > in case. > > Any ideas what might have happened here? > -- > John English > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
[jira] [Created] (OWB-1367) Bad filter url-pattern in demos
Greg Wilkins created OWB-1367: - Summary: Bad filter url-pattern in demos Key: OWB-1367 URL: https://issues.apache.org/jira/browse/OWB-1367 Project: OpenWebBeans Issue Type: Improvement Components: Samples Documentation Reporter: Greg Wilkins There is a * in: * [https://github.com/apache/openwebbeans/blob/master/webbeans-tomcat7/src/main/resources/META-INF/web-fragment.xml#L33] * [https://github.com/apache/openwebbeans/blob/master/webbeans-jetty9/src/main/resources/META-INF/web-fragment.xml#L33] The pattern '*' is not a legal url-pattern by [https://jakarta.ee/specifications/servlet/5.0/jakarta-servlet-spec-5.0.html#specification-of-mappings] Current jetty releases incorrectly accept '*' as a mapping, treating it like a suffix mapping with an empty suffix. I assume that tomcat must also accept it. Future versions of jetty will not accept it and the next version of jetty will accept it only with a warning. It should be "/*" -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [jetty-users] Graceful shutdown for custom connections
Josh, it is a little different in Jetty-9 vs jetty-10, but we may backport 10 changes to 9, so I will describe those. Typically a connector does not track requests, so it is not the connector that waits for requests to drain, but the StatsHandler instead. Any object in the component tree (the addBean, addHandler etc. on ContainerLifeCycle that is the server and it's handlers) may implement the Graceful interface and it will be called to obtain a Future that will be completed once it has gracefully shutdown. Some components just switch to a different mode - ie responses are now sent with Connection:close so connections are not persistent, whilst others take time: eg statshandler waits for dispatched request count to go to zero So you may need nothing more than to deploy the statshandler. But if you have special stuff in your connector, then implement Graceful and you should be called. cheers On Wed, 6 Jan 2021 at 01:27, Josh Spiegel wrote: > Hi, > > I've implemented a custom ConnectionFactory and Connection for a custom > protocol (not http). I've been using them with Server and > ServerConnector. I'd like to hook my connections into the Graceful > shutdown process that is already in place. i.e. I'd like to give my > connections a chance to write final responses within the getStopTimeout() > window. > > I'm not sure how I can add a Graceful instance into this process. Does > anybody know how to do this? > > Thanks, > Josh > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Another error after upgrading to jetty 9.4.34
Eze, There is nothing in that stack trace that is Jetty... other than the final class that it fails to load. So we can't really say other than something you are using (hivemind?) doesn't have it's classpath setup correctly? cheers On Wed, 11 Nov 2020 at 07:32, Eze Ikonne wrote: > Hi all, > > > > I am getting the stacktrace below after upgrading to Jetty 9.4.34, any > hints will be appreciated. > > > > Thanks, > > > > Ike > > > > > > 2020-11-10 16:22:21,775 [main] ERROR ServiceManagerImpl - > java.lang.NoClassDefFoundError: > org.eclipse.jetty.server.HttpConfiguration$Customizer > > at java.lang.Class.forNameImpl(Native Method) > > at java.lang.Class.forName(Class.java:337) > > at > com.sterlingcommerce.hadrian.hivemind.ServiceFactory.getInstance(ServiceFactory.java:63) > > at > com.sterlingcommerce.hadrian.hivemind.ServiceFactory.createCoreServiceImplementation(ServiceFactory.java:53) > > at > org.apache.hivemind.impl.InvokeFactoryServiceConstructor.constructCoreServiceImplementation(InvokeFactoryServiceConstructor.java:62) > > at > org.apache.hivemind.impl.servicemodel.AbstractServiceModelImpl.constructCoreServiceImplementation(AbstractServiceModelImpl.java:108) > > at > org.apache.hivemind.impl.servicemodel.AbstractServiceModelImpl.constructNewServiceImplementation(AbstractServiceModelImpl.java:158) > > at > org.apache.hivemind.impl.servicemodel.AbstractServiceModelImpl.constructServiceImplementation(AbstractServiceModelImpl.java:140) > > at > org.apache.hivemind.impl.servicemodel.SingletonServiceModel.getActualServiceImplementation(SingletonServiceModel.java:69) > > at > $ServiceWithLifecycle_175b1c8e7f9._service($ServiceWithLifecycle_175b1c8e7f9.java) > > at > $ServiceWithLifecycle_175b1c8e7f9.init($ServiceWithLifecycle_175b1c8e7f9.java) > > at > $ServiceWithLifecycle_175b1c8e7f8.init($ServiceWithLifecycle_175b1c8e7f8.java) > > at > com.sterlingcommerce.hadrian.system.ServiceManagerImpl.initStartGlobalServices(ServiceManagerImpl.java:195) > > at > com.sterlingcommerce.hadrian.system.ServiceManagerImpl.init(ServiceManagerImpl.java:248) > > at > $ServiceManager_175b1c8e7df.init($ServiceManager_175b1c8e7df.java) > > at > $ServiceManager_175b1c8e7de.init($ServiceManager_175b1c8e7de.java) > > at > $ServiceManager_175b1c8e7dd.init($ServiceManager_175b1c8e7dd.java) > > at com.sterlingcommerce.hadrian.Main.main(Main.java:134) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > > at java.lang.reflect.Method.invoke(Method.java:508) > > at com.zerog.lax.LAX.launch(Unknown Source) > > at com.zerog.lax.LAX.main(Unknown Source) > > Caused by: java.lang.ClassNotFoundException: > org.eclipse.jetty.server.HttpConfiguration$Customizer > > at > java.net.URLClassLoader.findClass(URLClassLoader.java:610) > > at > java.lang.ClassLoader.loadClassHelper(ClassLoader.java:944) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:889) > > at > sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:872) > > ... 24 more > > > > > = > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > = > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] org.eclipse.jetty.http.HttpField
So wrote this test code:
public void testEtag()
{
HttpFields fields = new HttpFields();
fields.add("ETag", "W/\"1\",W/2");
fields.add("ETag", "W/\"3\"");
System.err.println("Collections.list(fields.getValues(\"Etag\"))");
Collections.list(fields.getValues("Etag")).forEach(System.err::println);
System.err.println("Collections.list(fields.getValues(\"Etag\", \",\"))");
Collections.list(fields.getValues("Etag",
",")).forEach(System.err::println);
System.err.println("fields.getCSV(\"Etag\", false)");
fields.getCSV("Etag", false).forEach(System.err::println);
System.err.println("fields.getCSV(\"Etag\", true)");
fields.getCSV("Etag", true).forEach(System.err::println);
}
which cage the output:
Collections.list(fields.getValues("Etag"))
W/"1",W/2
W/"3"
Collections.list(fields.getValues("Etag", ","))
W/11111
W/2
W/3
fields.getCSV("Etag", false)
W/1
W/2
W/3
fields.getCSV("Etag", true)
W/"1"
W/2
W/"3"
So fields.getCSV("Etag", true) is the method you want.
Note also that fields.getValues("Etag", ",") is deprecated!
--
Greg Wilkins CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] org.eclipse.jetty.http.HttpField
Ohhh and yes section 2.3 doesn't comply with 2.6 but 2.6 does only apply to "most" values. ... and you wonder why implementations of these specs sometimes get it wrong:) On Fri, 30 Oct 2020, 00:32 Greg Wilkins, wrote: > My first thought is that Nils could be right when he says that getValues > is needlessly removing quotes. > > That method was never really well specified as it's based in neither the > http nor servlets specification. It was originally a jack of all trades > method that worked for most cases. > > We've not moved much of our previous handling to other methods like getCSV > and getQualityCSV, with more precise behaviour. > > In this case, getCSV passed a boolean to keep quotes will probably do the > job you need. > > I'll do a bit more of a review and comment more tomorrow if I get a > chance,... But maybe Monday. > > Cheers > > On Thu, 29 Oct 2020, 22:28 Joakim Erdfelt, wrote: > >> Per the spec you linked ... >> >> ETag = entity-tag >> >> entity-tag = [ weak ] opaque-tag >> weak = %x57.2F ; "W/", case-sensitive >> opaque-tag = DQUOTE *etagc DQUOTE >> etagc = %x21 / %x23-7E / obs-text >> ; VCHAR except double quotes, plus obs-text >> >> >> That means the "ETag" field is an "entity-tag" >> Which can start with an optional "weak", and must have an "opaque-tag" >> >> The definition fo "weak" is that it is always the 2 characters "W/" and >> the case must be preserved. >> >> The "opaque-tag" is almost the same as what the http/1.1 spec level >> "quoted-string" definition is. >> Except that it doesn't allow space character. >> >> Greg, what's you take on this? >> This would mean a new Special Case handling for a field value that isn't >> "Set-Cookie". >> There's some accepted errata published after RFC7232 about ETag, but only >> related to space in etagc. >> No errata on RFC7230 about other special case handling of field-values. >> >> Joakim Erdfelt / joa...@webtide.com >> >> >> On Thu, Oct 29, 2020 at 4:07 PM Cantor, Scott wrote: >> >>> On 10/29/20, 4:54 PM, "jetty-users-boun...@eclipse.org on behalf of >>> Joakim Erdfelt" >> joa...@webtide.com> wrote: >>> >>> >Your Example 2: >>> >If-Match: W/"ab3>5ef1bc78", W/"5be73a9c523" >>> > >>> > This is a field of name "If-Match". >>> > It has 2 values, both of which are in violation of the spec. >>> >>> https://tools.ietf.org/html/rfc7232#section-2.3 >>> >>> Am I missing something? That middle one seems to explicitly match your >>> examples that you think are in violation... >>> >>> (I don't mean to barge into the thread, but I have some uses of ETag in >>> our code stack and I want to be able to accurately assess how we're using >>> it.) >>> >>> -- Scott >>> >>> >>> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/jetty-users >>> >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] org.eclipse.jetty.http.HttpField
My first thought is that Nils could be right when he says that getValues is needlessly removing quotes. That method was never really well specified as it's based in neither the http nor servlets specification. It was originally a jack of all trades method that worked for most cases. We've not moved much of our previous handling to other methods like getCSV and getQualityCSV, with more precise behaviour. In this case, getCSV passed a boolean to keep quotes will probably do the job you need. I'll do a bit more of a review and comment more tomorrow if I get a chance,... But maybe Monday. Cheers On Thu, 29 Oct 2020, 22:28 Joakim Erdfelt, wrote: > Per the spec you linked ... > > ETag = entity-tag > > entity-tag = [ weak ] opaque-tag > weak = %x57.2F ; "W/", case-sensitive > opaque-tag = DQUOTE *etagc DQUOTE > etagc = %x21 / %x23-7E / obs-text > ; VCHAR except double quotes, plus obs-text > > > That means the "ETag" field is an "entity-tag" > Which can start with an optional "weak", and must have an "opaque-tag" > > The definition fo "weak" is that it is always the 2 characters "W/" and > the case must be preserved. > > The "opaque-tag" is almost the same as what the http/1.1 spec level > "quoted-string" definition is. > Except that it doesn't allow space character. > > Greg, what's you take on this? > This would mean a new Special Case handling for a field value that isn't > "Set-Cookie". > There's some accepted errata published after RFC7232 about ETag, but only > related to space in etagc. > No errata on RFC7230 about other special case handling of field-values. > > Joakim Erdfelt / joa...@webtide.com > > > On Thu, Oct 29, 2020 at 4:07 PM Cantor, Scott wrote: > >> On 10/29/20, 4:54 PM, "jetty-users-boun...@eclipse.org on behalf of >> Joakim Erdfelt" > joa...@webtide.com> wrote: >> >> >Your Example 2: >> >If-Match: W/"ab3>5ef1bc78", W/"5be73a9c523" >> > >> > This is a field of name "If-Match". >> > It has 2 values, both of which are in violation of the spec. >> >> https://tools.ietf.org/html/rfc7232#section-2.3 >> >> Am I missing something? That middle one seems to explicitly match your >> examples that you think are in violation... >> >> (I don't mean to barge into the thread, but I have some uses of ETag in >> our code stack and I want to be able to accurately assess how we're using >> it.) >> >> -- Scott >> >> >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Controlling Maximum Header and Maximum Form content size
Ike, See - https://github.com/eclipse/jetty.project/blob/jetty-9.4.20.v20190813/jetty-server/src/main/java/org/eclipse/jetty/server/HttpConfiguration.java - https://github.com/eclipse/jetty.project/blob/jetty-9.4.20.v20190813/jetty-server/src/main/java/org/eclipse/jetty/server/handler/ContextHandler.java#L1687 On Mon, 5 Oct 2020 at 17:49, Eze Ikonne wrote: > Hi all, > > > > I would like to know what method/API to set in order to control Maximum > Header length and Maximum Form content size. > > We are running embedded jetty-server-9.4.20.v20190813 and I would like to > control the Maximum Header Length size and Maximum Forrm content size. > > Also, what a potential test scenario would look like. We saw “WARN > HttpParser - Header is too large 8193>8192” in our log file and we would > like to control it. > > > > Thanks, > > > > Ike > = > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > = > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] When can we expect Jetty 10?
Michal, We are running a little late with 10 (massive understatement there). We are building beta releases of 10 and 11 in the next days and expect full releases this month. cheers On Fri, 2 Oct 2020 at 08:36, Michał Niklas wrote: > Hi, > > On the: > > https://projects.eclipse.org/projects/rt.jetty/releases/10.0 > > there is: > Release Date: > Wednesday, September 2, 2020 > > But there is no offical Jetty 10 release on download page. > > Question to Jetty 10 developers: when can we expect Jetty 10 release on > download page? > > -- > Regards, > Michał Niklas > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Cache-control
John, can you give me an actual sequence of requests and responses with all the headers. thanks On Thu, 6 Aug 2020 at 11:14, John English wrote: > On 04/08/2020 19:38, Greg Wilkins wrote: > > John, > > > > Can you capture some examples of headers from requests and responses > > that are not being cached. > > Closer inspection shows that pages are being cached, even though the > browsers don't show any cached data under "Memory" in the dev tools. The > header I'm getting is "Cache-control: max-age=0" and I get a 304 > response to tell the browser to use the cached copy. I'm not generating > the Cache-control header in my webapp. > > The fact that the CSS sometimes doesn't load makes me think that I'm > sometimes not getting the response...? > > > Also can you describe how you are serving the content as well? Is the > > CSS just static content? Do you have any filters involved? > > The CSS is static, so is being served by the default servlet. JavaScript > goes through a filter which does I18N translation for error messages > etc. on specially-tagged strings. When the CSS fails to load, I haven't > looked to see if the JS has loaded. Next time this happens, I'll have a > look at headers etc. to see if I can find out any more. > > Thanks, > -- > John English > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Cache-control
John, Can you capture some examples of headers from requests and responses that are not being cached. Also can you describe how you are serving the content as well? Is the CSS just static content? Do you have any filters involved? If you think there is a problem once you have the headers, opening an issue is probably a better way to discuss. cheers On Tue, 4 Aug 2020 at 13:37, John English wrote: > I have a webapp which I recently upgraded to use Jetty 9.4.30 and I'm > suddenly finding that CSS stylesheets are occasionally not loaded, and I > have to reload the affected pages to make them display correctly. > > Looking at the browser cache, I find that absolutely nothing is being > cached. This is true for both Firefox and Chrome. (AFAIK it used to > cache static resources before the upgrade to 9.4.30, but I might be > wrong about that...) > > Does anyone have any idea why this might be, and what I can do to find > out more about what's going on? > > -- > John English > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Interleaving requests for fairness/starvation?
Matt, if it is a file server, then you should do it asynchronously totally asynchronously with async IO. That way threads are not a problem and the fair share algorithms already built into TCP/IP and the OS will do all the work for you. So you startAsync, register a WriteListener and then Jetty will call you back with an onWritePossible call whenever a write can be done without blocking. You will then have to use async IO to actually read your content off disk and then write some.Look at our AsyncProxyServlet for an example... but replace to HttpClient with a File IO API. This can be a bit more complex code than you'd think but it is absolutely the right way to server files (or file like content). cheers On Mon, 1 Jun 2020 at 16:34, Matthew Boughen wrote: > Hi Greg > > Thank you very much for your suggestions, they're really useful. > > Yes - I was thinking that we need to limit the total number of threads, as > each of them can use a lot of memory. I guess we could increase the thread > pool size to something large, and put a fair semaphore around the actual > work. After 50ms work is done, a startAsync followed by an immediate > redispatch would, I think, preserve the behaviour of ThreadLimitHandler - > particularly that requests from a single client remain interleaved, due to > the FIFO queue per Remote. (correct me if I'm wrong!) > > I should also have mentioned that writing the response (and reading from > disk) is much of the work of each 50ms chunk. I guess it's something like > a file server. So the clients (which are generally not browsers) aren't > waiting minutes for the HTTP headers, and we need to stream the response > (as they can be very large). > > With the concurrent queue idea, I guess after each chunk of work, you > could always add yourself to the back of the queue and dispatch a request > from the front (which could be yourself - in that case it doesn't matter > that you're hogging a thread). You'd also need to reserve one thread to > accept new requests, which are immediately put on the queue (so no blocking > work is done). (I think you'd also need a reserved thread in your > suggestion?) > > Agreed that (assuming you agree with it) the non-async approach is > probably better. (It's also clearly better than a separate thread pool!) > > Best > > Matt > > -- > *From:* jetty-users-boun...@eclipse.org > on behalf of Greg Wilkins > *Sent:* 01 June 2020 13:31 > *To:* JETTY user mailing list > *Subject:* Re: [jetty-users] Interleaving requests for > fairness/starvation? > > Matt, > > Are you doing this to try to limit the total threads, or just to make sure > that some threads are not starving others? If you don't mind the total > number of threads, then you could simply put in a Thread.yield() call every > 50ms and not worry about async servlet handling. > > Note also, from a users perspective, having requests that can take many > minutes to respond is not great. If your clients are browsers, then it > could be better to separate your handling from the request/response thread > - ie start the handling and then immediately respond. Your clients could > then poll (or better yet long poll) to see progress and to get the final > state. > > I'm very cautious about any approach that changes the behaviour of the > threadpool, especially tryExecute. The behaviour there is all very finely > tuned to our scheduling strategies to avoid deadlocks and thread starvation. > > If you do want to use servlet async to do the interleaving, you need to > get other requests/threads to do the dispatching. EG every 50ms of > processing your app can look at a concurrent list to see if other processes > are waiting to be handled, if they are, then dispatch the first of them > then start async and add your AsyncContext to the end of the queue. The > problem with this approach is how does the first request ever get added to > the queue? Perhaps you need a limit on concurrent handling as well and if > you are above that, add yourself to the queue... if you finish handling and > reduce the handling count below the threshhold, then you can also wakeup > any waiting contexts on the queue. This is making Thread.yield feel > very simple. > > cheers > > > > > > On Mon, 1 Jun 2020 at 13:51, Matthew Boughen wrote: > > Hi > > I was wondering if anyone could confirm whether what we've done is > sensible - it seems to work, but I'm not really confident and would like to > know how righteous it is! > > Our HTTP server processes requests that can take minutes at a time, the > handling for which can easily be broken down into small chunks. We would > like to interleave the handling of these
Re: [jetty-users] Interleaving requests for fairness/starvation?
Matt, Are you doing this to try to limit the total threads, or just to make sure that some threads are not starving others? If you don't mind the total number of threads, then you could simply put in a Thread.yield() call every 50ms and not worry about async servlet handling. Note also, from a users perspective, having requests that can take many minutes to respond is not great. If your clients are browsers, then it could be better to separate your handling from the request/response thread - ie start the handling and then immediately respond. Your clients could then poll (or better yet long poll) to see progress and to get the final state. I'm very cautious about any approach that changes the behaviour of the threadpool, especially tryExecute. The behaviour there is all very finely tuned to our scheduling strategies to avoid deadlocks and thread starvation. If you do want to use servlet async to do the interleaving, you need to get other requests/threads to do the dispatching. EG every 50ms of processing your app can look at a concurrent list to see if other processes are waiting to be handled, if they are, then dispatch the first of them then start async and add your AsyncContext to the end of the queue. The problem with this approach is how does the first request ever get added to the queue? Perhaps you need a limit on concurrent handling as well and if you are above that, add yourself to the queue... if you finish handling and reduce the handling count below the threshhold, then you can also wakeup any waiting contexts on the queue. This is making Thread.yield feel very simple. cheers On Mon, 1 Jun 2020 at 13:51, Matthew Boughen wrote: > Hi > > I was wondering if anyone could confirm whether what we've done is > sensible - it seems to work, but I'm not really confident and would like to > know how righteous it is! > > Our HTTP server processes requests that can take minutes at a time, the > handling for which can easily be broken down into small chunks. We would > like to interleave the handling of these requests so that none get starved > and time out (and to help with fairness). For each request, after 50ms of > handling, we asynchronously suspend the request and (hope to) redispatch it > to the queue behind newly arrived requests / other more-recently suspended > requests. > > With this approach, the issue seems to be in choosing where to call > asyncContext.dispatch: too close to the suspend call (startAsync) and Jetty > will not release the thread back to allow processing of other queued > requests (presumably because Jetty thinks it's more efficient to avoid the > context switch and so immediately continues processing the current > request). > > We've currently settled on overriding QueuedThreadPool.execute(Runnable) > and tryExecute(Runnable) to wrap the Runnable: any request that had > registered itself while the original (unwrapped) Runnable was called is now > redispatched. This seems to work in that: (a) only one request attempts to > register itself each time a Runnable is run, (b) the redispatch normally > seems to happen very quickly after the request has registered itself, and > (c) the request handling is indeed interleaved. > > Does that sound like the right thing to do here? I'm thinking it would be > as long as each request handle is guaranteed to be the tail call of a task > submitted to the thread pool (I don't know enough about the use of > ExecutionStrategy to know this). > > Any suggestions/comments are highly appreciated. > > Matt > > > P.S. I'm anticipating that the right thing to do might be to use a > separate thread pool and manage the interleaving there? This of course would > incur another thread context switch / managing another pool. We're also > using ThreadLimitHandler to avoid single clients taking out the whole > server, so would need to duplicate that logic. > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Separate thread pools on separate requests Hello
Note also that you can use,modify or extend the QOSFilter (quality of service) filter and/or `LowResourceMonitor` to track simultaneous requests (thread), request rates, memory levels etc. You could then explicitly handle the healthcheck requests (before qos filter) and give a better answer if more load should be accepted based on all those factors. On Mon, 13 Apr 2020 at 18:06, Simone Bordet wrote: > Hi, > > On Mon, Apr 13, 2020 at 5:34 PM Stefano Bonetti > wrote: > > > > Hello, > > apologies if this is not the right group for such a request. > > > > I have a web app with a /healthcheck path which is used by the > infrastructure to detect failing applications. At present when my app is > under high load the healthcheck starts failing with 502s, so the > infrastructure starts terminating the app instances. > > Isn't this exactly what you want? > If the server is overloaded, the health check fails exactly because > the server is overloaded - you don't want to send more requests to an > overloaded server, right? > > > I was wondering if there is a way of serving some paths (namely the > healthcheck path) on a separate thread pool, so the healthcheck requests > are not affected by high load. > > It's more complicated than this. > > A new request may trigger the opening of a new connection. > The server may be overloaded not because it's running out of threads, > but because it cannot cope with more connections - thread pools are > not exactly in the game here. > > You have to carefully control also connection opening to isolate the > health check request. > > > Is there any way of doing it? > > You can create a new ServerConnector on a different port. > Each ServerConnector can be configured with its own thread pool. > The configuration for this ServerConnector should be minimal (e.g. > acceptors=1, selectors=1, small thread pool). > > Send the health check requests to the different port. > > -- > Simone Bordet > > http://cometd.org > http://webtide.com > Developer advice, training, services and support > from the Jetty & CometD experts. > _______ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] How to include another web page in a page served by Jetty?
On Tue, 31 Mar 2020 at 21:16, Alexander Farber wrote: > Thank you for your response Greg - > > > On Mon, Mar 30, 2020 at 10:09 AM Greg Wilkins wrote: > >> >> Jetty supports the Servlet API feature of RequestDispatcher.include, so >> one URI/resource can be included in another page. The trick is how do you >> trigger than in the content that you are generating?From the servlet, >> it should be easy enough to get a RequestDispatcher and call it directly. >> If you want to do this from static content, then you will need to use >> something like JSP to process that content and allow dynamic components to >> be added. For wordpress... either do it in wordpress... or do something >> very complex about intercepting responses and rewriting with the new >> content - possible but a lot of work. >> > > then I will better use jQuery in my test server pages to fetch and insert > the web page content > If client side is an option, there are always simple iframes as an option > Regards > Alex > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] How to include another web page in a page served by Jetty?
Jetty supports the Servlet API feature of RequestDispatcher.include, so one URI/resource can be included in another page. The trick is how do you trigger than in the content that you are generating?From the servlet, it should be easy enough to get a RequestDispatcher and call it directly. If you want to do this from static content, then you will need to use something like JSP to process that content and allow dynamic components to be added. For wordpress... either do it in wordpress... or do something very complex about intercepting responses and rewriting with the new content - possible but a lot of work. cheers On Sun, 29 Mar 2020 at 12:58, Alexander Farber wrote: > Hello, > > I am using Jetty 9.4.27.v20200227 - > > 1) in production server to server Wordpress/PHP and a Java servlet > 2) in test server started locally at my Macbook to serve the Java servlet > > I wonder if there is some kind of configuration statement for Jetty which > would allow me to include other web pages inside the HTML web page files > served by Jetty. > > Then I would be able to emulate more functionality from the production > server (which uses PHP to include other web pages/URLs) in my test server. > > Thank you for any hints > Alex > > PS: Below are the config files of my test server, they are pretty simple - > > jetty.base/webapps/words.xml (to serve some static HTML pages): > > > "http://www.eclipse.org/jetty/configure_9_0.dtd;> > > /words > > > name="jetty.base"/>/../words > true > > > > > jetty.base/webapps/ws.xml (for the servlet and WebSockets): > > > "http://www.eclipse.org/jetty/configure_9_0.dtd;> > > /ws > name="jetty.base"/>/../WebSockets/target/ws-servlet-0.1-SNAPSHOT.war > > > etc. > _______ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Can Jetty decide not to respond to a request?
and just to add some more options...
if you are using Jetty APIs then calling abort(Throwble) on the HttpChannel
is he best transport independent way to do a GO_AWAY style semantic.
Doing a sendError(-1) will also trigger an abort under the scenes (and can
be done from a servlet).
Finally, throwing BadMessageException is another way to handle this. It
will send a 400 and then close the connection.
cheers
On Mon, 16 Mar 2020 at 19:27, Simone Bordet wrote:
> Hi,
>
> On Mon, Mar 16, 2020 at 5:13 PM Glen Peterson
> wrote:
> >
> > My first choice would be to decide not to respond from within an
> AbstractHandler's handle() method, after examining the
> (HttpServlet)Request. But if there's another place we can examine the
> request (ideally in Java), that would work too. Right now I've got some
> code like:
> >
> > object MyHandler: AbstractHandler() {
> >
> > override fun handle(target: String,
> > baseRequest: Request,
> > request: HttpServletRequest,
> > response: HttpServletResponse) {
> >
> > val rawPath = request.getPathInfo()
> >
> > // We don't have any PHP files. Any attempt to access one is
> hacking.
> > if ( rawPath.endsWith(".php") ) {
> > logger.info("BOGUS Request: [${request.pathInfo}]")
>
> baseRequest.getHttpChannel().getEndPoint().close();
>
> However, in general is not that big of a difference to send a 400
> (response.sendError(400)), it's more standard and will work for the
> years in future.
>
> --
> Simone Bordet
>
> http://cometd.org
> http://webtide.com
> Developer advice, training, services and support
> from the Jetty & CometD experts.
> _______
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
--
Greg Wilkins CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] NoClassDefFoundError : Embedded Jetty
Sujay, thanks for the extra information. I can't tell a lot from your dump, because the classloaders just have WEB-INF/classes on their classpath. I'm guessing the problem is that your LoginService is being loaded by the Webapp classloader, and thus it does not have visibility of the server classes like Credential. So I would make sure that all of the classes you use for your login services are on the container class path (ie not in WEB-INF of any webapp). They are server classes and not application classes, so they should not be constrained by the webappclassloader. regards On Thu, 12 Mar 2020 at 21:08, Sujay Pujari wrote: > Hi Greg & other users, > > > > Please accept apologies from me. > > > > Last dump shared “Build_parentLoaderTrue_dumpStderr.txt” was for scenario > 1. i.e output from eclipse environment where set Parent Clasloade helped > to resolve No class def issue. > > > > Somehow I am not able to get DumpStdErr on my production build environment > ( i.e sccenario 2 where NCDFE is still persist). I will share with you dump > as soon as I get there. > > > > Regards, > > Sujay > > > > *From:* Sujay Pujari > *Sent:* Friday, March 13, 2020 12:58 AM > *To:* JETTY user mailing list > *Subject:* RE: [jetty-users] NoClassDefFoundError : Embedded Jetty > > > > Hi Greg, > > > > I just want to give more detail about our issue > > > > We have multiple web apps, and one of them is configured in ediscovery.xml. > > Also different login services are used for different applications. > > Hence we used per web app scoped : security handler approach instead of > addbean at server level. > > Ref: > https://www.eclipse.org/jetty/documentation/current/configuring-security.html > > > > Also, > >1. On eclipse IDE workspace , when we use parentLoaderPriority true >then we don’t face any such issue >2. Now when we have created a installer which copies this jars in >installation directory and a Java comman launches our server, then >parentLoaderPriority true is not helping us. > > > > PFA : Build_parentLoaderTrue_dumpStderr.txt > As output of Stderr when I ran dumpStdErr in Build environment. > > > > > > Thanks & Regards, > Sujay > > > > *From:* jetty-users-boun...@eclipse.org *On > Behalf Of *Greg Wilkins > *Sent:* Thursday, March 12, 2020 2:16 AM > *To:* JETTY user mailing list > *Subject:* Re: [jetty-users] NoClassDefFoundError : Embedded Jetty > > > > Sujey, > > > > Jetty 6 to Jetty 9!!! Happy new decade! !) > > > > After you start the server, can you do a Server.dumpStdErr() and post the > output? > > > > Your configuration of the login service by setting a new security handler > on the context is a bit strange. You should be able to just add the login > service as a bean on the server and it will be found. > > > > Do any of the frameworks you are using set the Thread context classloader? > > > > regards > > > > > > On Wed, 11 Mar 2020 at 20:18, Sujay Pujari > wrote: > > Hello Jetty users, > > > > We are migrating Jetty from v6 to ver 9.4.27 & using embedded Jetty. > > Where in authentication is performed using form based , Jaas > authentication. > > In Jaas.conf file we have configured to use following custom module > > class com.acme.es.nuvo.ediscovery.jaas.DiscoveryLoginModule which extends > from AbstractLoginModule. > > Now inside Login method of this class, We have following line of code > > Credential cr = Credential.getCredential(pwdStr); > > > > *Where we are getting NoClassDefFoundError for > org.eclipse.jetty.util.security.Credential.* > > Note : This issue is observed on Jetty 9.x & 8.x ( but was working fine > with 6.x ) > > > > Inspite of the fact that jetty-util jar corresponding to this is present > in the buildpath. > > Also, > > Verbose:class shows that this class is getting loaded. > > class load: org.eclipse.jetty.util.security.Credential from: > file:/../lib/Jetty9.4.15/jetty-util-9.4.15.v20190215.jar > > > > Can anybody suggest what I might be missing ? Any appropriate way to > troubleshoot this? > > Any help would be really appreciated. > > > > *Here is detailed stack:* > > > > javax.security.auth.login.LoginException: java.lang.NoClassDefFoundError: > org.eclipse.jetty.util.security.Credential > > at > com.acme.es.nuvo.ediscovery.jaas.DiscoveryLoginModule.login(DiscoveryLoginModule.java:148) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > a
Re: [jetty-users] NoClassDefFoundError : Embedded Jetty
t; at > org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) > > at > org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:543) > > at > org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:398) > > at > org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:161) > > at > org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) > > at > org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) > > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) > > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) > > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) > > at > org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) > > at > org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375) > > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806) > > at > org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938) > > at java.lang.Thread.run(Thread.java:785) > > Caused by: java.lang.ClassNotFoundException: > org.eclipse.jetty.util.security.Credential > > at > org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:565) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:809) > > ... 86 more > > > > > > Other details : > > > > A. > > We are instantiating jetty instance through Java code and where we refer > jetty.xml for server configuration. > > > > B. > > In jetty.xml we uses following > > > > > > … > > … > > > > > > > > *"org.eclipse.jetty.deploy.DeploymentManager"*> > > > > > > > > > > > >*"org.eclipse.jetty.deploy.providers.WebAppProvider"*> > > *"Project.home"* default=*"."* />/*config*/jetty_contexts > > > 0 > > true > > > > > > > > > > > > > > > > > > > … > > > > > > > > > > > > > > C. one of the file present at /*config*/jetty_contexts is > ediscovery.xml > > > > > > > > > > > > > > > > > > > > > > > > /*ediscovery* > > > > > /*lib*/Application_ui.war > > > > ….. > > > > > > > > > > > > > > *ediscovery* > > DiscoveryLoginModule > > > > org.eclipse.jetty.jaas.callback.DefaultCallbackHandler > > > > > > > > org.eclipse.jetty.jaas.JAASRole > > > > > > > > > > true > > > > > > > > … > > > > > > > > > > > > Now I have few observations. > > > > When in File C i.e. ediscovery.xml I make following line uncommented > > true > > Then, > > In my eclipse I don’t see any No Class Def Found Error. > > > > But, > >1. In my build environment ( installed version, I see same error , >classpath has required jars present ) >2. Jetty 6 we were nor setting parentLoaderPriority to True. > > > > > > > > > > Any help to troubleshoot this problem will be appreciated. > > > > Thanks & Regards, > > Sujay > DISCLAIMER > == > This e-mail may contain privileged and confidential information which is > the property of Persistent Systems Ltd. It is intended only for the use of > the individual or entity to which it is addressed. If you are not the > intended recipient, you are not authorized to read, retain, copy, print, > distribute or use this message. If you have received this communication in > error, please notify the sender and delete all copies of this message. > Persistent Systems Ltd. does not accept any liability for virus infected > mails. > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Questions about Jetty Security Maintenance
On Mon, 9 Mar 2020 at 23:29, Yicheng Wang wrote: > Hi team, > > We're migrating to Jetty and we do have some questions related with Jetty > maintenance. > > 1. Does Jetty have separate security patches or bugs are fixed within a new > release? > Occasionally we have had specific security patches, but our most common response to security issue is to release a new version. Typically this will be on all active branches (9.4 and 10.0), but if the issue is significant we also will do 9.2 and 9.3 releases as well. There are no security fixes for jetty < 9 > > 2. If Jetty does have security patches, how often are they provided? > As above, they are included in regular releases unless there is a very special case. I can recall only a single instance of us needing to provide a patched jar for existing releases. > 3. Does Jetty have a fixed schedule of upgrades? I looked at the release > log > of 9.4.x versions, and it's updated approximately monthly > No. We release as often as necessary - frequency varies from several weeks to several months > 4. We're running a standalone Jetty server, how can we upgrade Jetty to a > newer version? Just replace the ZIP file? > The intention of the jetty-home vs jetty-base layout is that you should not put any of your modifications into the unpacked jetty distribution - instead you put them all into a jetty-base directory.You can then upgrade simply by changing which jetty-home directory you are using. The following command sequence illustrates this: # set the jetty version JETTY_HOME=/opt/jetty-9.4.25 # create your application base directory mkdir myapp-base cd myapp-base # configure a server in the base directory java -jar $JETTY_HOME --create-startd --add-to-start=http,webapp,deploy vi start.d/server.ini # deploy your application cp $HOME/src/myapp/target/myapp.war webapp # start the server java -jar $JETTY_HOME # stop the server ^C # upgrade jetty JETTY_HOME=/opt/jetty-9.4.27 # start the upgraded server java -jar $JETTY_HOME > > Any help would be highly appreciated! > > Best, > Yicheng > > > > -- > Sent from: http://jetty.4.x6.nabble.com/Jetty-User-f3247280.html > ___ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Cross Context communication between WebApps without HTTP overhead
Manpreet, another option is to create a server side component that represents the communication between webapps and pass that into each webapp as a context attribute. On Mon, 9 Mar 2020 at 12:25, Jan Bartel wrote: > Have a look at the ServletContext.getContext and > ServletContext.getRequestDispatcher methods and read up in the spec on > request forwarding and including which happens only on the server side. > > Jan > > On Fri, 6 Mar 2020 at 07:33, Manpreet Singh > wrote: > >> Hi, >> >> >> >> What would be the best way in Jetty to have 2 web applications >> communicate with each other without using HTTP calls? >> >> >> >> Thanks, >> >> Manpreet >> >> >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users > > > > -- > Jan Bartel > www.webtide.com > *Expert assistance from the creators of Jetty and CometD* > > _______ > jetty-users mailing list > jetty-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 10
Josh, To our embarrassment, Jetty-10 has been expected release next month for the last 18 months! There is nothing really holding it up, other than a lack of demand for a 4.0 container. and the fact that we keep taking the opportunity to review and renew some internal APIs It will no longer support java-8, it will be servlet-4.0 There will be some API changes, but mostly for embedded usage rather than webapps. Our project plan has been out of date, so we do need to get a page on this. It is our intention to release next month and I would like to see an alpha out in the next few days. regards On Wed, 26 Feb 2020 at 16:09, Josh Spiegel wrote: > Hi, > > What is the expected timeline for Jetty 10? > > What versions of Java will it support? > > Are there expected to be any major backwards incompatible changes? > > I apologize in advance if there is a page that answers all these questions > - I wasn't able to find it. > > Thank you, > Josh > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Native memory leak in 9.4.x fixed in 9.4.26
Scott, thanks for this heads up. 26 did include a fix for a TLS timeout issue in https://github.com/eclipse/jetty.project/pull/4446 which could be related. cheers On Tue, 25 Feb 2020 at 19:31, Cantor, Scott wrote: > This is more of an FYI, but I thought it was worth pointing out. I've > observed a pretty massive native memory leak in 9.4.x since a fairly early > version of that branch. This is running natively, exclusively HTTPS, > directly exposed to clients, and it leaked a native buffer somewhere > frequently enough to observe unbounded RSS growth on Linux under Java 11. > > I had done some minimal tracing and got some evidence of the leak but > hadn't yet filed a bug about it due to the complexity of gathering enough > evidence to be actionable. > > I just happened to upgrade to 9.4.26 and the leak appears to be gone. > > I thought it was worth noting in case it's obvious to the devs what change > fixed the leak, and if not, well, you fixed something important. ;-) > > Diffing 25 and 26 only suggests a couple of likely areas of change that > could have fixed it. > > -- Scott Cantor > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Does Jetty Uses Session to Set the Principal in HTTP Request
If you are using BASIC auth (or DIGEST which is a little more secure) then it is the responsibility of your client to send auth headers with every request and the server will validate every request from scratch and populate the auth fields of the request. Browsers do this by default. but it sounds like you are not using a browser. There are other methods such as FORM and OPENID that do an authentication conversation and leave the results in a session, so that all following requests in the same session are considered authenticated.Now by default FORM auth does use HTML pages to run a conversation, but ultimately it does not need those pages to do the auth, it just needs: - one GET request to establish a session (could be for anything and could get a 401 response) - a POST request to "/j_security_check" with parameters "j_username" and "j_password" - all subsequent requests carrying the session cookie will then be authenticated. Ultimately our authenticators and authentications are pluggable and you can do all sorts of stuff. It would not be hard to authenticate with BASIC, save that in a session and then all subsequent requests would be authenticated. The login module is used by all of these auth methods to check the credentials - either for every request or once to put in the session. So it is orthogonal to the auth method used. Finally, Webtide LLC is available for commercial services and we can implement a custom auth mechanism for you as part of that if none of the standard mechanisms works for you and you don 't want to customize yourself. cheers On Mon, 24 Feb 2020 at 23:46, Wang Yicheng wrote: > Hi Greg, > > Yes, I've got the point that BASIC is bound to be stateless and work > without session. And we did observe the authentication header in the first > request while the second one didn't carry it. > > I think our question is, we do need sessions to keep users logged in, but > we don't have HTML pages as FORM asks for. In this case, which > authentication method should we use? And I suppose all auth-methods support > JAAS customized login module right? > > Do apologize if any of my previous questions are vague or misleading :) > > On Mon, Feb 24, 2020 at 2:04 PM Greg Wilkins wrote: > >> OK, >> >> so if you are using BASIC auth, then you don't need sessions, so we're >> barking up the wrong tree! >> >> Can you share the headers of your first and second requests? Does the >> second request have the authentication header? >> >> cheers >> >> >> >> On Mon, 24 Feb 2020 at 20:21, Wang Yicheng >> wrote: >> >>> Sorry for the late reply. Yes we use BASIC as the authentication method. >>> It works fine with WebLogic without extra configuration to create sessions. >>> So I supposed Jetty would do the same at the beginning. The thing is our >>> system doesn't have HTML pages as we only use the web server for >>> remote communication. >>> >>> I've tried to change the to FORM in web.xml but it's >>> prompting that the pages are needed. I simply put "/" for the login page >>> and the error page but then the customized login module is not working >>> properly. We have a servlet for domain "/" but it wouldn't return any HTML >>> pages. I didn't get a chance to do further investigation. >>> >>> Any suggestions would be appreciated! >>> >>> On Sun, Feb 23, 2020 at 10:02 AM Greg Wilkins wrote: >>> >>>> >>>> What auth mechanism are you using? >>>> BASIC and DIGEST send auth information with every request >>>> FORM stores the auth in the session. >>>> >>>> You can have other varieties (eg OPENID) which do either, but you need >>>> to set an authenticator to do whatever auth conversation you want to have. >>>> >>>> So tell us a bit more detail about your actual authentication mechanism. >>>> >>>> cheers >>>> >>>> >>>> >>>> >>>> On Wed, 19 Feb 2020 at 11:23, Jan Bartel wrote: >>>> >>>>> If you use BASIC authentication, every single request must contain the >>>>> realm, username and password and is authenticated on reception - there is >>>>> no concept of a session maintaining state. >>>>> >>>>> The form login page can be generated by a servlet, it doesn't have to >>>>> be a static html resource. >>>>> >>>>> Jan >>>>> >>>>> On Tue, 18 Feb 2020 at 20:34, Wang Yicheng >>>>> wrote: >>&
Re: [jetty-users] Does Jetty Uses Session to Set the Principal in HTTP Request
OK, so if you are using BASIC auth, then you don't need sessions, so we're barking up the wrong tree! Can you share the headers of your first and second requests? Does the second request have the authentication header? cheers On Mon, 24 Feb 2020 at 20:21, Wang Yicheng wrote: > Sorry for the late reply. Yes we use BASIC as the authentication method. > It works fine with WebLogic without extra configuration to create sessions. > So I supposed Jetty would do the same at the beginning. The thing is our > system doesn't have HTML pages as we only use the web server for > remote communication. > > I've tried to change the to FORM in web.xml but it's > prompting that the pages are needed. I simply put "/" for the login page > and the error page but then the customized login module is not working > properly. We have a servlet for domain "/" but it wouldn't return any HTML > pages. I didn't get a chance to do further investigation. > > Any suggestions would be appreciated! > > On Sun, Feb 23, 2020 at 10:02 AM Greg Wilkins wrote: > >> >> What auth mechanism are you using? >> BASIC and DIGEST send auth information with every request >> FORM stores the auth in the session. >> >> You can have other varieties (eg OPENID) which do either, but you need to >> set an authenticator to do whatever auth conversation you want to have. >> >> So tell us a bit more detail about your actual authentication mechanism. >> >> cheers >> >> >> >> >> On Wed, 19 Feb 2020 at 11:23, Jan Bartel wrote: >> >>> If you use BASIC authentication, every single request must contain the >>> realm, username and password and is authenticated on reception - there is >>> no concept of a session maintaining state. >>> >>> The form login page can be generated by a servlet, it doesn't have to be >>> a static html resource. >>> >>> Jan >>> >>> On Tue, 18 Feb 2020 at 20:34, Wang Yicheng >>> wrote: >>> >>>> Thanks Jan! The thing is, my project actually doesn't have any pages. >>>> So, is it possible to have FORM authentication without login pages? Or does >>>> it mean I should go with BASIC while create sessions myself? >>>> >>>> On Mon, Feb 17, 2020 at 2:16 AM Jan Bartel wrote: >>>> >>>>> You need to set up what the authentication method is, ie the >>>>> equivalent of the in web.xml. >>>>> The default is basic authentication. If you want to use sessions to >>>>> maintain the authentication state, then configure FORM authentication, >>>>> either in web.xml or by setting an instance of >>>>> https://www.eclipse.org/jetty/javadoc/9.4.26.v20200117/org/eclipse/jetty/security/authentication/FormAuthenticator.html >>>>> on the SecurityHandler. >>>>> >>>>> Jan >>>>> >>>>> On Mon, 10 Feb 2020 at 23:12, Wang Yicheng >>>>> wrote: >>>>> >>>>>> Thanks Joakim! >>>>>> >>>>>> Yes I do have a customized login module following JAAS spec. So it >>>>>> seems the missing session is causing the problem. Then my question is: >>>>>> With >>>>>> default configuration, does Jetty generate session automatically for >>>>>> authenticated user? Or is my code responsible for doing that? >>>>>> >>>>>> I actually published another question here >>>>>> <http://jetty.4.x6.nabble.com/HttpServletRequest-Returns-NULL-Principal-After-Logging-In-td4968503.html> >>>>>> which contains more details about my issue. Any help is highly >>>>>> appreciated! >>>>>> >>>>>> Best >>>>>> >>>>>> On Mon, Feb 10, 2020 at 1:11 PM Joakim Erdfelt >>>>>> wrote: >>>>>> >>>>>>> If using Servlet authentication (or JAAS) the principal would be set. >>>>>>> >>>>>>> If you are using a 3rd party web library (like spring) then odds are >>>>>>> you are not integrating with Servlet security. >>>>>>> >>>>>>> Joakim Erdfelt / joa...@webtide.com >>>>>>> >>>>>>> >>>>>>> On Mon, Feb 10, 2020 at 2:05 PM Yicheng Wang < >>>>>>> wangyicheng1...@gmail.com> wrote: >>>>>>> >>>>>>>> Hi team, >>>
Re: [jetty-users] Does Jetty Uses Session to Set the Principal in HTTP Request
your delivery options, retrieve your password, or unsubscribe >>>> from this list, visit >>>> https://www.eclipse.org/mailman/listinfo/jetty-users >>> >>> >>> >>> -- >>> Jan Bartel >>> www.webtide.com >>> *Expert assistance from the creators of Jetty and CometD* >>> >>> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://www.eclipse.org/mailman/listinfo/jetty-users >> >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users > > > > -- > Jan Bartel > www.webtide.com > *Expert assistance from the creators of Jetty and CometD* > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Modifying HTTP response content with a servlet filter
The response wrapper approach is historically how such transformations were done. However it is a lot of boilerplate code, very easy to get wrong and fails completely if the async IO API is used. So another approach to consider is to use the jetty API for interceptors (see GzipHandler for an example) that will work with any content source. Ultimately I'd like to propose a standards based approach for this in Servlet-5.x, but it will be a while before such new features can be considered because of the distraction of renaming everything to jakarta.servlet.* cheers On Tue, 18 Feb 2020 at 12:55, Peter Boughton wrote: > Hi, > > I need to modify the content of responses, so I'm writing a filter. > > I found a couple of different approaches here: > > https://stackoverflow.com/questions/14736328/looking-for-an-example-for-inserting-content-into-the-response-using-a-servlet-f#14736818 > > The simpler solution from iTech works - but only when directly > requesting a file. > > i.e. example.com/dir/index.html works, but example.com/dir/ returns the > unmodified content of index.html > > The longer (accepted) solution works in both cases, so I'm guessing its > convoluted use of getOutputStream/etc is somehow relevant to it working, > but I don't see why the same file triggers different behaviour, just > because it's going via the default/welcome file mechanism. > > Is it really necessary to jump through all those hoops in order to get > and set response content, or am I missing some simpler way? > > > Thanks, > > Peter > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Communication between a Servlet and a custom protocol
Generally communication between components in the server space and those in the application space is best done by using a context attribute (with a lot of care about classpath visibility). On Mon, 20 Jan 2020 at 00:36, Josh Spiegel wrote: > Hi, > > What is the cleanest way for a servlet (e.g. in a war file under webapps) > to communicate state with a custom ConnectionFactory running in the same > server?Is there is some way to set Server attributes from the servlet or > something like that? > > A static variable would probably work for me but I am hoping for something > that is more decoupled and scoped at the Server level. > > Thanks, > Josh > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] IllegalStateException in org.eclipse.jetty.server.HttpOutput#write(byte[], int, int)
Eric, correct diagnosis! We have already fixed this (see https://github.com/eclipse/jetty.project/issues/4461) and a new release will be coming soon. regards On Fri, 10 Jan 2020 at 12:45, Eric Theriault wrote: > Hi-- > > > > I have just upgraded to 9.4.25.v20191220 and I have a piece of code that > calls org.apache.commons.io.IOUtils.copy(inputStream, outputStream), where > the outputStream is an instance of HttpOutput -- this code essentially just > reads the code in chunks of 4096 bytes and writes that to the outputStream. > > For one stream in particular (I'm still trying to figure out what is > different with it), after sending 64,428 bytes, it sets the _apiState to > BLOCKED. When the next segment is copied over, however, the _apiState is > still BLOCKED and falls into the default case which throws > an IllegalStateException. > > I've traced through the code and in line 806, I wonder why the code does > not call onWriteComplete as would happen in line 835. Is that the bug? Or > is there something more subtle here? > > > https://github.com/eclipse/jetty.project/blob/jetty-9.4.25.v20191220/jetty-server/src/main/java/org/eclipse/jetty/server/HttpOutput.java#L806 > > > https://github.com/eclipse/jetty.project/blob/jetty-9.4.25.v20191220/jetty-server/src/main/java/org/eclipse/jetty/server/HttpOutput.java#L835 > > Looks like this was recently changed in > https://github.com/eclipse/jetty.project/pull/4409 if I understand > correctly. > > This is the exception for reference: > > java.lang.IllegalStateException: s=OPEN,api=BLOCKED,sc=false,e=null > at > org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:767)~[jetty-server-9.4.25.v20191220.jar:9.4.25.v20191220] > at > org.springframework.security.web.util.OnCommittedResponseWrapper$SaveContextServletOutputStream.write(OnCommittedResponseWrapper.java:639) > ~[spring-security-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] > at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:2315) > ~[commons-io-2.6.jar:2.6] > at org.apache.commons.io.IOUtils.copy(IOUtils.java:2270) > ~[commons-io-2.6.jar:2.6] > at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:2291) > ~[commons-io-2.6.jar:2.6] > at org.apache.commons.io.IOUtils.copy(IOUtils.java:2246) > ~[commons-io-2.6.jar:2.6] > > Thanks for any insight. > > > > > Eric > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Equivalent of HandlerList for Servlets
Bill,
Jetty has Proxy and Middleman components that can be used for load
balancing. Using jetty for balancing will never be as efficient as
dedicated balancers, however it can be a good idea if:
+ the decision of what back end to use is complex and needs to inspect the
request
+ if processing/transformation is to be done in the load balancer of
either request/response
+ the application is much more of a load than running the protocol, so
that any extra inefficiencies of app space balancing would be outweighed by
the gains from reducing load on the app servers themselves.
regards
On Sat, 14 Dec 2019 at 11:25, Bill Ross wrote:
> > But the question would be, how is the correct handler going to be picked
> from that list?
>
> Out of curiosity, would it be efficient/maintainable to use Jetty as a
> load balancer, such that each handler would manage load for a given back
> end, and they'd be chosen by sorting handlers (hanglers once you can
> misspell) according to load?
>
> Bill
> On 12/13/19 3:07 PM, Greg Wilkins wrote:
>
>
> Note also that if you have a need, there is nothing preventing you from
> having a HandlerList within a ContextHandler.
>
> But the question would be, how is the correct handler going to be picked
> from that list?
>
> For ContextHandlerCollection, the context path (and some virtual host
> stuff) is used to pick which ContextHandler the request is given to.
> For a normal HandlerList, each listed handler is called in turn until one
> of them handles it.
> A ServletHandler picks a servlet by the pathInfo and will always handle a
> request - if only with a 404, so a HandlerList of normal ServletHandlers
> makes little sense.
>
> But if you have some other criteria to select between different
> ServletHandlers, then you can have a custom HandlerList within a context
> that could apply that criteria.
>
>
>
>
>
>
> On Fri, 13 Dec 2019 at 23:55, Karel Goderis wrote:
>
>> Thanks Joakim
>>
>> That’s clear.
>>
>> The stages do in fact respond to the same URL endpoint; I will have quick
>> look if Filters (that filter based on some PDU bytes) can be a solution for
>> this kind of situation
>>
>> Thanks
>> K
>>
>> On 13 Dec 2019, at 12:03, Joakim Erdfelt wrote:
>>
>> Since you haven't details what your ServletHandler are actually trying to
>> do ("stage 1, stage 2, stage 3" means nothing), this reply is generic.
>>
>> A ServletContextHandler belongs to a single context Path.
>>
>> It manages the ServletContext for all Servlets and Filters and Listeners
>> belonging to that ServletContext.
>>
>> Each Servlet has a url-pattern it can belong to
>> Each Filter has a url-pattern it can participate in.
>>
>> If you have multiple ServletHandlers, and expect them to respond on the
>> same url-pattern, then you have a problem.
>>
>> You should only have 1 "endpoint" to a HTTP resource.
>> You *can* have that single "endpoint" respond differently depending on
>> request details (such as method, Content-Type, existence of request body
>> content, Accept headers, Cache headers, etc...)
>> But that difference isn't handled by multiple servlets, it's handled by a
>> single servlet, with logic to produce different responses accordingly.
>>
>> If you have multiple ServletHandlers because some handlers respond on
>> different url-patterns, then great! You just use different url-patterns
>> when you add them to the ServletContextHandler.
>>
>> If you have multiple ServletHandlers because each handler does some
>> subset of actions, then you are abusing ServletHandlers.
>> Use Filters for subsets and Servlets for "endpoint" logic.
>>
>> Joakim Erdfelt / joa...@webtide.com
>>
>>
>> On Fri, Dec 13, 2019 at 4:37 AM Karel Goderis
>> wrote:
>>
>>> Yes,
>>>
>>> I am using a ServletConextHandler, however the question is : can you do
>>> the equivalent of HandlerList but with Servlets. AFAIK it is impossible to
>>> register different Servlets using the same Context path
>>>
>>> Tx
>>> K
>>>
>>> On 13 Dec 2019, at 11:33, Joakim Erdfelt wrote:
>>>
>>> Use a ServletContextHandler.
>>>
>>> Don't use ServletHandlers, those are internal structures not meant for
>>> direct usage.
>>>
>>> Use ServletContextHandler.addServlet() and
>>> ServletContextHandler.addFilter()
>>> You can add the Servlet as a Class reference, or as a Servlet instances
>>> (via a ServletHolder).
>>>
>>> Joakim Erdf
Re: [jetty-users] Jetty 9.4.24 prints warning messages to stderr
Silvio, This is the second time I've heard about a problem fetching browser resources like CSS or js. Can you attach the stacks you are seeing? On Mon, 2 Dec 2019, 22:58 Silvio Bierman, wrote: > Hi Greg, > > The last few days exceptions have started to come up in the logging. We > can quite easily reproduce them by testing common parts of our web > applications using Firefox. Using Chrome the same actions do not produce > exceptions (or warnings). > > Strangely enough this seems to intermittently fail mostly (but not > exclusively) on plain GET requests for CSS resources that are requested by > the browser as a result of an @import from another CSS resource. > > We serve the files ourselves from a servlet. Perhaps we are doing > something that triggers this? GET requests for which we serve the response > content dynamically seem to work fine. The same goes for POSTs. Since it > only happens via one of our code paths I suspect we are causing this in > some way, although the code is extremely simple. > > Kind regards, > > Silvio > > > On 11/29/19 12:27 AM, Greg Wilkins wrote: > > > Silvio, > > I believe it is ignorable and you can turn the HttpChannelState logger > level down to suppress them. > However, if there a stack trace associated with that warning then it is > not what I think it is and you need to provide more information. > > What I believe is happening is that while a request is being processed, > the associated HTTP/2 stream is being reset (probably by the client?) > This asynchronous error is detected but because the request is not async, > it cannot be delivered to the request and instead we warn. This is > probably over verbose as clients can do silly things like close mid request > handling. > > @Simone Bordet what do you think? > > cheers > > > > > > > > > > > > On Fri, 29 Nov 2019 at 09:03, Silvio Bierman > wrote: > >> Hello all, >> >> Ever since upgrading to 9.4.24 our stderr-log is filled with these >> messages: >> >> 2019-11-28 22:56:27.469:WARN:oejs.HttpChannelState:qtp1519100796-25: >> org.eclipse.jetty.io.EofException: Reset cancel_stream_error >> >> Can anyone tell me what this means? I take it the situation is not >> critical because the application has worked flawlessly for years with >> earlier Jetty versions without these messages. Can I turn this off? >> >> Kind regards, >> >> Silvio >> >> _______ >> jetty-users mailing list >> jetty-users@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > > > -- > Greg Wilkins CTO http://webtide.com > > ___ > jetty-users mailing listjetty-us...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visithttps://www.eclipse.org/mailman/listinfo/jetty-users > > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Jetty 9.4.24 prints warning messages to stderr
Silvio, I believe it is ignorable and you can turn the HttpChannelState logger level down to suppress them. However, if there a stack trace associated with that warning then it is not what I think it is and you need to provide more information. What I believe is happening is that while a request is being processed, the associated HTTP/2 stream is being reset (probably by the client?) This asynchronous error is detected but because the request is not async, it cannot be delivered to the request and instead we warn. This is probably over verbose as clients can do silly things like close mid request handling. @Simone Bordet what do you think? cheers On Fri, 29 Nov 2019 at 09:03, Silvio Bierman wrote: > Hello all, > > Ever since upgrading to 9.4.24 our stderr-log is filled with these > messages: > > 2019-11-28 22:56:27.469:WARN:oejs.HttpChannelState:qtp1519100796-25: > org.eclipse.jetty.io.EofException: Reset cancel_stream_error > > Can anyone tell me what this means? I take it the situation is not > critical because the application has worked flawlessly for years with > earlier Jetty versions without these messages. Can I turn this off? > > Kind regards, > > Silvio > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] webapps
The order is determined by the scanner mechanism which has a map iterator. The order is thus indeterminate. If an order is needed, then you probably need to replace the deployer with a fixed XML that adds each of your webapps in order. On Tue, 26 Nov 2019 at 06:17, wrote: > Hi, > > is the a way to specify the order in which the applications in webapps > should be started? Or is there a build in order which i don't know about? > > Regards > walter > -- > My projects: > > Admin Boundaries of the World <https://wambachers-osm.website/boundaries> > Missing Boundaries > <https://wambachers-osm.website/index.php/projekte/internationale-administrative-grenzen/missing-boundaries> > Emergency Map <https://wambachers-osm.website/emergency> > Postal Code Map (Germany only) <https://wambachers-osm.website/plz> > Fools (QA for zipcodes in Germany) <https://wambachers-osm.website/fools> > Postcode Boundaries of Germany > <https://wambachers-osm.website/pcoundaries> > OSM Software Watchlist > <https://wambachers-osm.website/index.php/osm-software-watchlist> > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] jetty 10
David, Yes indeed - the creation of Jetty 10 has been a few months away for the last 2 years! We have delayed it somewhat because there has been little demand for the servlet 4.0 features that it has and there have been lots of changes on the horizon for things like Java-13, JPMS, Jakarta renaming etc. Having it in Alpha state has allowed us to adapt to these changes without creating yet another branch for them. But it is long past due that we stabilized and released 10. It is our intention to make it our main release in Q1 next year, with some alpha and beta releases in the next few months. Out of interest, what is the feature you are seeking from 10? regards On Thu, 14 Nov 2019 at 20:27, David Karlsen wrote: > https://www.eclipse.org/lists/jetty-users/msg06997.html > Seems like the 10 branch was created quite some time ago - when is 10 > targeted for release / what is the version roadmaps? > > -- > -- > David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Using Jetty transparent http proxy to forward to public website
Martin,
With a transparent proxy as you are using, you need to proxy all the
links. The issue is that you are injecting a /myproxy servlet path into
the "transparent" proxy, so you are transforming request for
http://127.0.0.1:7070/myproxy/ to requests for http://htmlhelp.com/.
Plus you are not translating any of the image and link requests that will
be going to /* rather than /myproxy/*
If you registered the transparent proxy servlet at /* it would probably
work fine.
If you really wanted to, you could rewrite the host header, but then all
images and links would bypass your proxy and you would lose capture of the
client.
cheers
On Mon, 4 Nov 2019 at 20:00, Martin Brentnall
wrote:
> Hi everyone,
>
> I'm trying to use Jetty transparent proxy to forward to a public web
> server, but currently unable to get a simple example working as I would
> expect. This is my code:
>
>
> --- CODE BEGIN ---
>
>
> package test.myproxy;
>
> import org.eclipse.jetty.proxy.ProxyServlet;
> import org.eclipse.jetty.server.Server;
> import org.eclipse.jetty.servlet.ServletContextHandler;
> import org.eclipse.jetty.servlet.ServletHolder;
>
> public class MyHttpProxy {
> public static void main(String[] args) {
> try {
> Server mServer = new Server(7070);
> ServletContextHandler mContext = new ServletContextHandler(mServer,
> "/");
> ServletHolder mHolder =
> mContext.addServlet(ProxyServlet.Transparent.class, "/myproxy/*");
> mHolder.setInitOrder(1);
> mHolder.setInitParameter("proxyTo", "http://www.htmlhelp.com;);
> mHolder.setInitParameter("prefix", "/myproxy");
> mServer.start();
> mServer.join();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
>
>
> --- CODE END ---
>
>
> When I run this, I can access the website htmlhelp.com in Chrome via the
> URL http://127.0.0.1:7070/myproxy/ as expected. However, the links and
> images on the page do not work, since they all refer to "127.0.0.1:7070/"
> (rather than "127.0.0.1:7070/myproxy/"). So for example, "
> http://127.0.0.1:7070/about/;, "http://127.0.0.1:7070/icon/wdglogo.gif;,
> etc. which of course are not recognised URL's on the Jetty server.
>
> On further investigation, I learned that the HTTP request includes
> headers, one of which is "host". It seems that a website uses this header
> to construct the link and image URL's. Indeed, if I change the "host"
> header in the debugger to "htmlhelp.com" immediately before the request
> is sent, then everything loads as expected.
>
> Now as I understand, the "host" header is an "end to end" header, meaning
> that the proxy should NOT modify it, so it seems that isn't an option.
> Besides, doing this would cause image loading and links to bypass the proxy
> anyway.
>
> Is it possible to accomplish what I'm trying to do? Apologies for the
> newbie question; this HTTP and web stuff is still quite new to me.
>
> In case it makes any difference, I'm using Jetty 9.0.7.
>
> --
> With Kind Regards,
> Martin Brentnall
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
--
Greg Wilkins CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] IOException: 11/invalid_priority_frame_rate
We are looking at the default... however I think the bigger problem is that we added this limit as per connector rather than per connection. We will fix that in the next release so the rate limit will scale with bigger servers. regards -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] IOException: 11/invalid_priority_frame_rate
gt; ... 29 more >> Suppressed: java.lang.Throwable: HttpInput failure >> at >> org.eclipse.jetty.server.HttpInput.failed(HttpInput.java:823) >> at >> org.eclipse.jetty.http2.server.HttpChannelOverHTTP2.onFailure(HttpChannelOverHTTP2.java:323) >> at >> org.eclipse.jetty.http2.server.HTTP2ServerConnection.onStreamFailure(HTTP2ServerConnection.java:221) >> at >> org.eclipse.jetty.http2.server.HTTP2ServerConnection.onSessionFailure(HTTP2ServerConnection.java:261) >> at >> org.eclipse.jetty.http2.server.HTTP2ServerConnectionFactory$HTTPServerSessionListener.onFailure(HTTP2ServerConnectionFactory.java:128) >> at >> org.eclipse.jetty.http2.HTTP2Session.notifyFailure(HTTP2Session.java:1156) >> ... 29 more >> Suppressed: java.lang.Throwable: HttpInput failure >> at >> org.eclipse.jetty.server.HttpInput.failed(HttpInput.java:823) >> at >> org.eclipse.jetty.http2.server.HttpChannelOverHTTP2.onFailure(HttpChannelOverHTTP2.java:323) >> at >> org.eclipse.jetty.http2.server.HTTP2ServerConnection.onStreamFailure(HTTP2ServerConnection.java:221) >> at >> org.eclipse.jetty.http2.server.HTTP2ServerConnection.onSessionFailure(HTTP2ServerConnection.java:261) >> at >> org.eclipse.jetty.http2.server.HTTP2ServerConnectionFactory$HTTPServerSessionListener.onFailure(HTTP2ServerConnectionFactory.java:128) >> at >> org.eclipse.jetty.http2.HTTP2Session.notifyFailure(HTTP2Session.java:1156) >> ... 29 more >> >> Thanks for your help! >> Óscar >> >> ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Should fully consume the InputStream of InputStreamResponseListener before close it?
Close on the input stream will not close the connection. But it will cause the server that is writing content to have a broken pipe exception and then they will close the connection. If the server is not confident the request/response cycle has completed normally, then it will close the connection. ditto for the client. On Wed, 9 Oct 2019 at 17:28, Đạt Cao Mạnh wrote: > Hi Greg, > > I just want to confirm, close() here is called on InputStream. By calling > that it will close the underlying connection too? And it even true in case > of HTTP/2? > > Thanks a lot! > > Vào Th 4, 9 thg 10, 2019 lúc 05:28 Greg Wilkins đã > viết: > >> >> Cao, >> >> The answer is "it depends". >> >> Closing the stream will result in the connection being closed and not >> reused for other requests. Making new connections can be expensive, >> especially if SSL is used, plus new connections are often slower than old >> connections as their flow control windows are not well sized. >> >> So fully consuming some content so a connection may be reused may be >> cheaper than closing... but if generating the data is expensive or there is >> a lot of data yet to come, then perhaps not. >> >> so your mileage may vary! >> >> >> >> >> >> >> >> On Wed, 9 Oct 2019 at 01:56, Đạt Cao Mạnh >> wrote: >> >>> Hi guys, >>> >>> I kinda see this pattern frequently in Apache HttpClient >>> >>> Please note that if response content is not fully consumed the underlying >>> connection cannot be safely re-used and will be shut down and discarded by >>> the connection manager. >>> >>> >>> Wondering it will be the same pattern need to apply when uses >>> *InputStreamResponseListener*? Based on Javadoc >>> >>> If the consumer is faster than the producer, then the consumer will block >>> with the typical InputStream.read() semantic. If the consumer is slower >>> than the producer, then the producer will block until the client consumes >>> >>> So I kinda assume that close() without fully consume the *InputStream* will >>> be better (since producer doesn't need to put more data into the stream). >>> Is that true? >>> >>> Thanks! >>> *--* >>> *Cao Mạnh Đạt* >>> *E-mail: caomanhdat...@gmail.com * >>> >> ___ >>> jetty-users mailing list >>> jetty-users@eclipse.org >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://www.eclipse.org/mailman/listinfo/jetty-users >> >> >> >> -- >> Greg Wilkins CTO http://webtide.com >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users > > -- > *Best regards,* > *Cao Mạnh Đạt* > *E-mail: caomanhdat...@gmail.com * > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Should fully consume the InputStream of InputStreamResponseListener before close it?
Cao, The answer is "it depends". Closing the stream will result in the connection being closed and not reused for other requests. Making new connections can be expensive, especially if SSL is used, plus new connections are often slower than old connections as their flow control windows are not well sized. So fully consuming some content so a connection may be reused may be cheaper than closing... but if generating the data is expensive or there is a lot of data yet to come, then perhaps not. so your mileage may vary! On Wed, 9 Oct 2019 at 01:56, Đạt Cao Mạnh wrote: > Hi guys, > > I kinda see this pattern frequently in Apache HttpClient > > Please note that if response content is not fully consumed the underlying > connection cannot be safely re-used and will be shut down and discarded by > the connection manager. > > > Wondering it will be the same pattern need to apply when uses > *InputStreamResponseListener*? Based on Javadoc > > If the consumer is faster than the producer, then the consumer will block > with the typical InputStream.read() semantic. If the consumer is slower than > the producer, then the producer will block until the client consumes > > So I kinda assume that close() without fully consume the *InputStream* will > be better (since producer doesn't need to put more data into the stream). > Is that true? > > Thanks! > *--* > *Cao Mạnh Đạt* > *E-mail: caomanhdat...@gmail.com * > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] curl: (56) Unexpected EOF
Glen, not it's not just the META-INF/services/org.eclipse.jetty.http.HttpFieldPreEncoder file I'm concerned with, but any META-INF/services/* file, with examples including: - com.sun.net.httpserver.spi.HttpServerProvider - javax.servlet.ServletContainerInitializer - javax.websocket.ContainerProvider - javax.websocket.server.ServerEndpointConfig$Configurator - org.apache.juli.logging.Log - org.eclipse.jetty.http.HttpFieldPreEncoder - org.eclipse.jetty.io.ssl.ALPNProcessor$Client - org.eclipse.jetty.io.ssl.ALPNProcessor$Server - org.eclipse.jetty.websocket.api.extensions.Extension - org.eclipse.jetty.xml.ConfigurationProcessorFactory The ServicesResourceTransformer linked by Steven is probably what you need to make sure all these files are correctly shaded. On Tue, 8 Oct 2019 at 06:56, Steven Schlansker wrote: > > > On Oct 7, 2019, at 12:33 PM, Glen Peterson > wrote: > > ... > > I'm using the Maven Shade plugin. What would you recommend as a better > tool to make a fat jar? I tried Gradle too, but went back to Maven > specifically because the Shade plugin had better debugging info than the > Gradle Shadow plugin. Maybe I just don't know how to work it. > > Are you familiar with > https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ServicesResourceTransformer > ? That's how we got this working in the past (before we ditched shading > entirely since it's such a mess). > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] curl: (56) Unexpected EOF
A good tool to create a fat jar should merged META-INF service files for
you. There are probably a couple of other ones that need to be merged in
the code base... more so once you go to jetty 10.
cheers
On Sat, 5 Oct 2019 at 10:16, Glen Peterson
wrote:
> SWEET! That fixed it. I just added the line:
> org.eclipse.jetty.http2.hpack.HpackFieldPreEncoder
> And it worked! Hallelujah!
>
> Is that something I can configure with code?
>
> On Fri, Oct 4, 2019 at 8:12 PM Glen Peterson
> wrote:
>
>> Yes. It has a single line:
>> org.eclipse.jetty.http.Http1FieldPreEncoder
>>
>> Should it have 2 lines? What if I just disallow that file altogether?
>>
>> On Fri, Oct 4, 2019 at 8:10 PM Greg Wilkins wrote:
>>
>>>
>>> Glen,
>>>
>>> it is not a matter of if the classes are in the jar or not. It is a
>>> matter of if the META-INF/services has been correctly configured to load
>>> them with the ServiceLoader.
>>>
>>> Does your jar have
>>> a META-INF/services/org.eclipse.jetty.http.HttpFieldPreEncoder file and if
>>> so, what is it's contents?
>>>
>>>
>>>
>>> On Sat, 5 Oct 2019 at 10:05, Glen Peterson
>>> wrote:
>>>
>>>> I may have been able to really simplify my example. Here's the entire
>>>> main method that works when run from class files, and fails when run from
>>>> the jar:
>>>>
>>>> val bb: ByteBuffer = ByteBuffer.allocate(100)
>>>>
>>>> PreEncodedHttpField("hello", "world").putTo(bb, HttpVersion.HTTP_1_0)
>>>> logger.info("hello world http 1.0: " + bb)
>>>>
>>>> PreEncodedHttpField("hello", "world").putTo(bb, HttpVersion.HTTP_1_1)
>>>> logger.info("hello world http 1.1: " + bb)
>>>>
>>>> PreEncodedHttpField("hello", "world").putTo(bb, HttpVersion.HTTP_2)
>>>> logger.info("hello world http 2: " + bb)
>>>>
>>>> OUTPUT (from Jar - breaks):
>>>> hello world http 1.0: java.nio.HeapByteBuffer[pos=14 lim=100 cap=100]
>>>> hello world http 1.1: java.nio.HeapByteBuffer[pos=28 lim=100 cap=100]
>>>> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException:
>>>> Index 1 out of bounds for length 1
>>>> at
>>>> org.eclipse.jetty.http.PreEncodedHttpField.putTo(PreEncodedHttpField.java:118)
>>>> at org.organicdesign.classVsJar.ClazzVsJarKt.main(ClazzVsJar.kt:84)
>>>>
>>>> From classes it ends with:
>>>> hello world http 2: java.nio.HeapByteBuffer[pos=39 lim=100 cap=100]
>>>>
>>>>
>>>> Greg Wilkins:
>>>> logger.info("http1fieldpreEncoderVersion = " +
>>>> org.eclipse.jetty.http.Http1FieldPreEncoder().httpVersion)
>>>> logger.info("http2fieldpreEncoderVersion = " +
>>>> org.eclipse.jetty.http2.hpack.HpackFieldPreEncoder().httpVersion)
>>>>
>>>> Output:
>>>> http1fieldpreEncoderVersion = HTTP/1.0
>>>> http2fieldpreEncoderVersion = HTTP/2.0
>>>>
>>>> So both are in the Jar and successfully loaded by the JVM. Maybe I'm
>>>> getting an older version of one of them from another jar? Presumably
>>>> another jetty jar? My IDE doesn't give me a choice for where to import
>>>> them from, so I don't know where another version could be coming from.
>>>>
>>>>
>>>> On Fri, Oct 4, 2019 at 7:34 PM Glen Peterson
>>>> wrote:
>>>>
>>>>> It *works* with http1.1 (I will also look more at the fat-jar thing):
>>>>>
>>>>> $ curl --http1.1 --verbose --insecure https://localhost:8443 -D
>>>>> headers.txt
>>>>> * Rebuilt URL to: https://localhost:8443/
>>>>> * Trying 127.0.0.1...
>>>>> * TCP_NODELAY set
>>>>> * Connected to localhost (127.0.0.1) port 8443 (#0)
>>>>> * ALPN, offering http/1.1
>>>>> * successfully set certificate verify locations:
>>>>> * CAfile: /etc/ssl/certs/ca-certificates.crt
>>>>> CApath: /etc/ssl/certs
>>>>> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
>>>>> * TLSv1.3 (IN), TLS handshake, Server hello (2):
>>>>> * TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
>>>>> * TLSv1.3 (IN), TLS handshake, Unknown (8):
>>>>> * TLSv1.3 (IN), TLS han
Re: [jetty-users] curl: (56) Unexpected EOF
Glen,
it is not a matter of if the classes are in the jar or not. It is a matter
of if the META-INF/services has been correctly configured to load them with
the ServiceLoader.
Does your jar have
a META-INF/services/org.eclipse.jetty.http.HttpFieldPreEncoder file and if
so, what is it's contents?
On Sat, 5 Oct 2019 at 10:05, Glen Peterson
wrote:
> I may have been able to really simplify my example. Here's the entire
> main method that works when run from class files, and fails when run from
> the jar:
>
> val bb: ByteBuffer = ByteBuffer.allocate(100)
>
> PreEncodedHttpField("hello", "world").putTo(bb, HttpVersion.HTTP_1_0)
> logger.info("hello world http 1.0: " + bb)
>
> PreEncodedHttpField("hello", "world").putTo(bb, HttpVersion.HTTP_1_1)
> logger.info("hello world http 1.1: " + bb)
>
> PreEncodedHttpField("hello", "world").putTo(bb, HttpVersion.HTTP_2)
> logger.info("hello world http 2: " + bb)
>
> OUTPUT (from Jar - breaks):
> hello world http 1.0: java.nio.HeapByteBuffer[pos=14 lim=100 cap=100]
> hello world http 1.1: java.nio.HeapByteBuffer[pos=28 lim=100 cap=100]
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index
> 1 out of bounds for length 1
> at
> org.eclipse.jetty.http.PreEncodedHttpField.putTo(PreEncodedHttpField.java:118)
> at org.organicdesign.classVsJar.ClazzVsJarKt.main(ClazzVsJar.kt:84)
>
> From classes it ends with:
> hello world http 2: java.nio.HeapByteBuffer[pos=39 lim=100 cap=100]
>
>
> Greg Wilkins:
> logger.info("http1fieldpreEncoderVersion = " +
> org.eclipse.jetty.http.Http1FieldPreEncoder().httpVersion)
> logger.info("http2fieldpreEncoderVersion = " +
> org.eclipse.jetty.http2.hpack.HpackFieldPreEncoder().httpVersion)
>
> Output:
> http1fieldpreEncoderVersion = HTTP/1.0
> http2fieldpreEncoderVersion = HTTP/2.0
>
> So both are in the Jar and successfully loaded by the JVM. Maybe I'm
> getting an older version of one of them from another jar? Presumably
> another jetty jar? My IDE doesn't give me a choice for where to import
> them from, so I don't know where another version could be coming from.
>
>
> On Fri, Oct 4, 2019 at 7:34 PM Glen Peterson
> wrote:
>
>> It *works* with http1.1 (I will also look more at the fat-jar thing):
>>
>> $ curl --http1.1 --verbose --insecure https://localhost:8443 -D
>> headers.txt
>> * Rebuilt URL to: https://localhost:8443/
>> * Trying 127.0.0.1...
>> * TCP_NODELAY set
>> * Connected to localhost (127.0.0.1) port 8443 (#0)
>> * ALPN, offering http/1.1
>> * successfully set certificate verify locations:
>> * CAfile: /etc/ssl/certs/ca-certificates.crt
>> CApath: /etc/ssl/certs
>> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
>> * TLSv1.3 (IN), TLS handshake, Server hello (2):
>> * TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
>> * TLSv1.3 (IN), TLS handshake, Unknown (8):
>> * TLSv1.3 (IN), TLS handshake, Certificate (11):
>> * TLSv1.3 (IN), TLS handshake, CERT verify (15):
>> * TLSv1.3 (IN), TLS handshake, Finished (20):
>> * TLSv1.3 (OUT), TLS change cipher, Client hello (1):
>> * TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):
>> * TLSv1.3 (OUT), TLS handshake, Finished (20):
>> * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
>> * ALPN, server accepted to use http/1.1
>> * Server certificate:
>> * subject: C=US; ST=South Carolina; L=Upstate; O=OrganicDesign;
>> OU=Testing; CN=classVsJar.organicdesign.org
>> * start date: Oct 2 20:53:35 2019 GMT
>> * expire date: Oct 2 20:53:35 2022 GMT
>> * issuer: C=US; ST=South Carolina; L=Upstate; O=OrganicDesign;
>> OU=Testing; CN=classVsJar.organicdesign.org
>> * SSL certificate verify result: self signed certificate (18),
>> continuing anyway.
>> * TLSv1.3 (OUT), TLS Unknown, Unknown (23):
>> > GET / HTTP/1.1
>> > Host: localhost:8443
>> > User-Agent: curl/7.58.0
>> > Accept: */*
>> >
>> * TLSv1.3 (IN), TLS Unknown, Unknown (23):
>> < HTTP/1.1 200 OK
>> < Content-Type: text/html;charset=utf-8
>> < Content-Length: 178
>> < Server: Jetty(9.4.20.v20190813)
>> <
>> * TLSv1.3 (IN), TLS Unknown, Unknown (23):
>>
>>
>>
>>
>> Test Page
>>
>>
>> It works!
>> Working.
>>
>>
>> * Connection #0 to host localhost left intact
>>
>> On Fri, Oct 4, 2019 at 6:32 PM Greg Wilkins wrote:
>>
>>> I'm guessing the problem is the way you make your fat jar you m
Re: [jetty-users] ServletContextListener defers server start
Dirk, Note that you can actually achieve this with just a little bit of work: Write a simple context (extend context handler) that all it does is send a 503 with whatever message you want. Deploy both that context and your context at the same context path. The 503 context will handle all the requests as it is first. Once your context is started, stop and/or remove the 503 context. On Sat, 5 Oct 2019 at 00:48, Joakim Erdfelt wrote: > Sounds like the initial deployment on Server.start() is the reason you are > experiencing this. > > Your environment would need to delay deployment until after the server has > started up. > That would be a new feature / configuration (and not that hard to > implement either) > Can you file an issue for a new feature at > https://github.com/eclipse/jetty.project/issues > > And the extra requirement of a 503 before the webapp is available is a new > feature that Jetty does not have. > That would likely need to be a custom Handler at the end of your Handler > tree (but before the DefaultHandler) to > check the submitted context path and return 503 in those situations. > (as if it reached that custom handler, that means the webapp isn't there > yet) > That can also be a new feature, submit the idea at > https://github.com/eclipse/jetty.project/issues > > Joakim Erdfelt / joa...@webtide.com > > > On Fri, Oct 4, 2019 at 9:02 AM Dirk Olmes wrote: > >> Hi, >> >> I'm using an embedded Jetty to set up a servlet context. My code looks >> quite similar to what's in the "Embedding ServletContexts" section of >> the "Embedding Jetty" chapter of the Jetty docs. >> >> I noticed that the server (more correctly the ServerConnector) won't be >> ready to accept connections unless my servlets have started up. Now I >> have a ServletContextListener that takes a long time to start up. >> >> Would it be possible to configure Jetty in such a way that it already >> accepts connections and answers e.g. with a 503 status until the servlet >> context is finally up and running? >> >> -dirk >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > _______ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] curl: (56) Unexpected EOF
sName` it works. But >>>>>> if >>>>>> I run from the fat-jar file it doesn't work. >>>>>> >>>>>> *curl* >>>>>> >>>>>> *Jar File Failure:* >>>>>> $ curl --insecure https://dev.memoryjoggerlibrary.com:8443 -D >>>>>> headers.txt >>>>>> curl: (56) Unexpected EOF >>>>>> $ ls -s >>>>>> total 0 >>>>>> 0 headers.txt >>>>>> >>>>>> *Class Files Success:* >>>>>> That same curl command returns the HTML file I was expecting when >>>>>> running with the massive classpath (no fat-jar), plus the following >>>>>> headers.txt: >>>>>> HTTP/2 200 >>>>>> server: Jetty(9.4.20.v20190813) >>>>>> content-type: text/html;charset=utf-8 >>>>>> >>>>>> I have determined that the jar files included by maven exactly match >>>>>> the jar files specified on the command line. >>>>>> >>>>>> *Chrome* >>>>>> With chrome, the class files work great, but the Jar file produces, >>>>>> "This site can’t be reached... unexpectedly closed the connection... >>>>>> ERR_CONNECTION_CLOSED" >>>>>> >>>>>> *Unaffected* >>>>>> *Log Files:* >>>>>> I can see in the log files in both cases that the request is being >>>>>> processed, but there is no exception thrown and no response apparently >>>>>> written. >>>>>> >>>>>> *Nmap Cipher Test:* >>>>>> Whether it yields HTML or not, the server gives the same response to >>>>>> my cipher test: >>>>>> $ nmap --script ssl-cert,ssl-enum-ciphers -p 8443 >>>>>> dev.memoryjoggerlibrary.com >>>>>> >>>>>> Starting Nmap 7.60 ( https://nmap.org ) at 2019-10-02 13:32 EDT >>>>>> Nmap scan report for dev.memoryjoggerlibrary.com (127.0.0.1) >>>>>> Host is up (0.53s latency). >>>>>> rDNS record for 127.0.0.1: localhost >>>>>> >>>>>> PORT STATE SERVICE >>>>>> 8443/tcp open https-alt >>>>>> | ssl-cert: Subject: commonName= >>>>>> dev.memoryjoggerlibrary.com/organizationName=PlanBase >>>>>> Inc./stateOrProvinceName=Massachusetts/countryName=US >>>>>> | Issuer: commonName= >>>>>> dev.memoryjoggerlibrary.com/organizationName=PlanBase >>>>>> Inc./stateOrProvinceName=Massachusetts/countryName=US >>>>>> | Public Key type: rsa >>>>>> | Public Key bits: 2048 >>>>>> | Signature Algorithm: sha256WithRSAEncryption >>>>>> | Not valid before: 2019-09-25T20:57:00 >>>>>> | Not valid after: 2022-09-25T20:57:00 >>>>>> | MD5: 483e 988f 709f 7300 3f3d 1d51 4f95 81cb >>>>>> |_SHA-1: abe8 c872 c7d7 dfb1 4152 8bf3 2fee 5617 7613 94cd >>>>>> | ssl-enum-ciphers: >>>>>> | TLSv1.2: >>>>>> | ciphers: >>>>>> | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A >>>>>> | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A >>>>>> | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (rsa 2048) - A >>>>>> | compressors: >>>>>> | NULL >>>>>> | cipher preference: server >>>>>> |_ least strength: A >>>>>> >>>>>> Nmap done: 1 IP address (1 host up) scanned in 0.19 seconds >>>>>> >>>>>> *Details:* >>>>>> I'm using a self-signed certificate. >>>>>> >>>>>> Currently using (from maven .pom): >>>>>> 9.4.20.v20190813 >>>>>> jetty-server >>>>>> jetty-alpn-conscrypt-server >>>>>> http2-common >>>>>> http2-hpack >>>>>> http2-server >>>>>> >>>>>> Not currently using: conscrypt-openjdk (seems to be overridden by the >>>>>> conscrypt-openjdk-uber included in jetty-alpn-conscrypt-server - same >>>>>> issues with or without this dependency) >>>>>> >>>>>> >>>>>> -- >>>>>> Glen K. Peterson >>>>>> (828) 393-0081 >>>>>> >>>>> >>>>> >>>>> -- >>>>> Glen K. Peterson >>>>> (828) 393-0081 >>>>> ___ >>>>> jetty-users mailing list >>>>> jetty-users@eclipse.org >>>>> To change your delivery options, retrieve your password, or >>>>> unsubscribe from this list, visit >>>>> https://www.eclipse.org/mailman/listinfo/jetty-users >>>> >>>> ___ >>>> jetty-users mailing list >>>> jetty-users@eclipse.org >>>> To change your delivery options, retrieve your password, or unsubscribe >>>> from this list, visit >>>> https://www.eclipse.org/mailman/listinfo/jetty-users >>> >>> >>> >>> -- >>> Glen K. Peterson >>> (828) 393-0081 >>> >> >> >> -- >> Glen K. Peterson >> (828) 393-0081 >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users > > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Memory leak in Conscrypt with Jetty.
Luke, can you have a read of https://github.com/eclipse/jetty.project/issues/3111 and see if you are seeing the same problem? regards On Thu, 26 Sep 2019 at 17:22, Luke B wrote: > Hi, > > A memory leak exists in with Jetty and Conscrypt, I have replicated this > in: > > https://github.com/LukeButters/conscrypt-jetty > > you can see a pretty graph of the mem usage over a a ten day period: > > > https://raw.githubusercontent.com/LukeButters/conscrypt-jetty/master/sample/mem_over_time.png > > please help, > > -Luke > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Why does push request contain query string?
The spec for pushbuilder in 4.0 says that it will be initialized with the query string: https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/PushBuilder.html On Tue, 17 Sep 2019 at 09:26, Greg Wilkins wrote: > The PushBuilder is initialized with all the headers and query string of > the existing request. You have to reset the query string if you don't > want it. This looks deliberate in the code but need to check if it > really is intended by the spec. > > On Tue, 17 Sep 2019 at 01:58, Simone Bordet wrote: > >> Hi, >> >> On Mon, Sep 16, 2019 at 5:26 PM John Jiang >> wrote: >> > >> > Hi, >> > I'm using Jetty 10.0.0-alpha0 >> > Please consider this case: >> > 1. Client sends request for the below url, >> > http://host:port/push?query >> > 2. Server pushes some resources, including img1, img2. >> > The push requests look like the followings, >> > http://host:port/img1?query >> > http://host:port/img2?query >> > >> > Does it make sense that the query string is always in the push requests? >> >> That does not look right. >> Can you please open an issue about this? >> >> -- >> Simone Bordet >> >> http://cometd.org >> http://webtide.com >> Developer advice, training, services and support >> from the Jetty & CometD experts. >> ___ >> jetty-users mailing list >> jetty-users@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users >> > > > -- > Greg Wilkins CTO http://webtide.com > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
Re: [jetty-users] Why does push request contain query string?
The PushBuilder is initialized with all the headers and query string of the existing request. You have to reset the query string if you don't want it. This looks deliberate in the code but need to check if it really is intended by the spec. On Tue, 17 Sep 2019 at 01:58, Simone Bordet wrote: > Hi, > > On Mon, Sep 16, 2019 at 5:26 PM John Jiang > wrote: > > > > Hi, > > I'm using Jetty 10.0.0-alpha0 > > Please consider this case: > > 1. Client sends request for the below url, > > http://host:port/push?query > > 2. Server pushes some resources, including img1, img2. > > The push requests look like the followings, > > http://host:port/img1?query > > http://host:port/img2?query > > > > Does it make sense that the query string is always in the push requests? > > That does not look right. > Can you please open an issue about this? > > -- > Simone Bordet > > http://cometd.org > http://webtide.com > Developer advice, training, services and support > from the Jetty & CometD experts. > ___ > jetty-users mailing list > jetty-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins CTO http://webtide.com ___ jetty-users mailing list jetty-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
[weld-commits] [weld/core] c5b20b: WELD-2597 Rename the attributes for Jetty integrat...
Branch: refs/heads/master Home: https://github.com/weld/core Commit: c5b20b05f62acf062c7a565c0ead73c294e7f8a1 https://github.com/weld/core/commit/c5b20b05f62acf062c7a565c0ead73c294e7f8a1 Author: Greg Wilkins Date: 2019-09-10 (Tue, 10 Sep 2019) Changed paths: M docs/reference/src/main/asciidoc/environments.asciidoc M environments/servlet/core/src/main/java/org/jboss/weld/environment/jetty/JettyContainer.java M environments/servlet/core/src/main/java/org/jboss/weld/environment/jetty/WeldDecorator.java M environments/servlet/core/src/main/java/org/jboss/weld/environment/servlet/logging/JettyLogger.java Log Message: --- WELD-2597 Rename the attributes for Jetty integration #2587 (#1933) * WELD-2597 Rename the attributes for Jetty integration #2587 Signed-off-by: Greg Wilkins ___ weld-commits mailing list weld-commits@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-commits
