You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mark Miller (JIRA)" <ji...@apache.org> on 2016/02/20 23:37:18 UTC
[jira] [Comment Edited] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3
[ https://issues.apache.org/jira/browse/SOLR-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15155784#comment-15155784 ]
Mark Miller edited comment on SOLR-7339 at 2/20/16 10:36 PM:
-------------------------------------------------------------
[~gregw@webtide.com], [~joakime], looks like a default locale bug:
HttpParser
{code}
for (String charset : new String[]{"utf-8","iso-8859-1"})
{
CACHE.put(new PreEncodedHttpField(HttpHeader.CONTENT_TYPE,type+";charset="+charset));
CACHE.put(new PreEncodedHttpField(HttpHeader.CONTENT_TYPE,type+"; charset="+charset));
CACHE.put(new PreEncodedHttpField(HttpHeader.CONTENT_TYPE,type+";charset="+charset.toUpperCase()));
CACHE.put(new PreEncodedHttpField(HttpHeader.CONTENT_TYPE,type+"; charset="+charset.toUpperCase()));
}
{code}
toUpperCase should use an ENGLISH locale or I guess our project has determined ROOT is better because ENGLISH could change over time. The turkish bug.
*FYI*
Our project uses this tool to ban default locale method calls: https://github.com/policeman-tools/forbidden-apis
was (Author: markrmiller@gmail.com):
[~gregw@webtide.com], [~joakime], looks like a default locale bug:
HttpParser
{code}
for (String charset : new String[]{"utf-8","iso-8859-1"})
{
CACHE.put(new PreEncodedHttpField(HttpHeader.CONTENT_TYPE,type+";charset="+charset));
CACHE.put(new PreEncodedHttpField(HttpHeader.CONTENT_TYPE,type+"; charset="+charset));
CACHE.put(new PreEncodedHttpField(HttpHeader.CONTENT_TYPE,type+";charset="+charset.toUpperCase()));
CACHE.put(new PreEncodedHttpField(HttpHeader.CONTENT_TYPE,type+"; charset="+charset.toUpperCase()));
}
{code}
toUpperCase should use an ENGLISH locale or I guess our project has determined ROOT is better because ENGLISH could change over time. The turkish bug.
> Upgrade Jetty from 9.2 to 9.3
> -----------------------------
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
> Issue Type: Improvement
> Reporter: Gregg Donovan
> Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-7339-revert.patch, SOLR-7339.patch, SOLR-7339.patch, SOLR-7339.patch, SolrExampleStreamingBinaryTest.testUpdateField-jetty92.pcapng, SolrExampleStreamingBinaryTest.testUpdateField-jetty93.pcapng
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading Jetty. The server configuration would need to change and a new HTTP client ([Jetty's own client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], [Square's OkHttp|http://square.github.io/okhttp/], [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need to be selected and wired up. Perhaps this is worthy of a branch?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org