Return-Path: 
 <dev-return-125325-apmail-lucene-dev-archive=lucene.apache.org@lucene.apache.org>
X-Original-To: apmail-lucene-dev-archive@www.apache.org
Delivered-To: apmail-lucene-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 4F46BE2DF
	for <apmail-lucene-dev-archive@www.apache.org>;
 Thu, 28 Feb 2013 13:25:14 +0000 (UTC)
Received: (qmail 34746 invoked by uid 500); 28 Feb 2013 13:25:13 -0000
Delivered-To: apmail-lucene-dev-archive@lucene.apache.org
Received: (qmail 34621 invoked by uid 500); 28 Feb 2013 13:25:13 -0000
Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@lucene.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@lucene.apache.org>
List-Post: <mailto:dev@lucene.apache.org>
List-Id: <dev.lucene.apache.org>
Reply-To: dev@lucene.apache.org
Delivered-To: mailing list dev@lucene.apache.org
Received: (qmail 34606 invoked by uid 99); 28 Feb 2013 13:25:12 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Feb 2013 13:25:12 +0000
Date: Thu, 28 Feb 2013 13:25:12 +0000 (UTC)
From: =?utf-8?Q?Jan_H=C3=B8ydahl_=28JIRA=29?= <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12404335.1221442900392.357751.1362057912512@arcas>
In-Reply-To: <JIRA.12404335.1221442900392@arcas>
References: <JIRA.12404335.1221442900392@arcas>
Subject: [jira] [Commented] (SOLR-772) malformed XML updates w/Resin's Stax
 parser doesn't trigger errors
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/SOLR-772?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D135895=
30#comment-13589530 ]=20

Jan H=C3=B8ydahl commented on SOLR-772:
----------------------------------

Anyone running Solr in Resin who can do a quick test and (un)confirm this a=
ncient bug running one of the curl commands above?
               =20
> malformed XML updates w/Resin's Stax parser doesn't trigger errors
> ------------------------------------------------------------------
>
>                 Key: SOLR-772
>                 URL: https://issues.apache.org/jira/browse/SOLR-772
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Hoss Man
>
> Originally noted by yonik on the mailing list...
> {quote}
> Then I tried Resin 3.1.1 and 3.1.6....
> Things *seem* to mostly work... until you get to updating:
>    ...
> Now here is another really weird thing... post any garbage to the
> update URL, and you still get a success!  It successfully fails on
> jetty.  Mangled query requests correctly fail.  This perhaps initially
> points to something specific to the XML config in jetty?
> {quote}
> Followup from Hoss...
> {quote}
> Skimming the code in XmlUpdateRequestHandler, and testing out various inp=
uts, this seems like a bug in com.caucho.xml.stream.XMLStreamReaderImpl.
> Using curl as yonik described...
> curl -i http://localhost:8080/solr/update --data-binary 'crap' -H 'Conten=
t-type:text/xml; charset=3Dutf-8'
> ...resin-3.1.6 (on Linux) returns a success (incorrectly) but the request=
=20
> handler doesn't log any action taken. if we alter they payload ('crap')=
=20
> above we can see some different behaviors...
> 1) 'crap<add><doc><field name=3D"id">hoss</field></doc></add>'
> Solr adds the doc, ignorant of the crap before the add command
> 2) 'crap<add><doc></doc></add>'
> Solr correctly complains about the missing id field (example configs requ=
ire it)
> 3) 'crap<add>'
> Solr returns success even though it's not legal XML
> 4) 'crap<add'
> Get the following exception...
> {noformat}
> javax.xml.stream.XMLStreamException: :1:7 Expected > at 0xffffffff
>         at com.caucho.xml.stream.XMLStreamReaderImpl.error(XMLStreamReade=
rImpl.java:1268)
>         at com.caucho.xml.stream.XMLStreamReaderImpl.readElementBegin(XML=
StreamReaderImpl.java:689)
>         at com.caucho.xml.stream.XMLStreamReaderImpl.readNext(XMLStreamRe=
aderImpl.java:653)
>         at com.caucho.xml.stream.XMLStreamReaderImpl.next(XMLStreamReader=
Impl.java:594)
>         at org.apache.solr.handler.XmlUpdateRequestHandler.processUpdate(=
XmlUpdateRequestHandler.java:148)
> {noformat}
> 5) '<add><doc>'
> This appears to hang ... the connection seems to be left open as if it's =
waiting for more data.
> ...
> None of these 5 things happen when testing with Jetty.
> I'm not really very familiar with this StaX stuff -- but I suspect what's=
 happening here is that on "wacky" input Caucho's XMLStreamReaderImpl.next(=
) is returning values we're not expecting instead of throwing exceptions ..=
. and depending on the input, this is either causing the XmlUpdateRequestHa=
ndler.processUpdate loop/switch to ignore the garbage data, or get stuck in=
 an infinite loop (when there is no END_DOCUMENT)
> The question is: Are we doing the right thing, and com.caucho.xml.stream.=
XMLStreamReaderImpl is broken; or is XMLStreamReaderImpl producing a legal =
sequence of parse events for those bad inputs and we're not dealing with it=
 properly?
> FWIW: adding the following line to our web.xml seems to make everything "=
work" (by which i mean: "fail") as expected...
> <system-property javax.xml.stream.XMLInputFactory=3D"com.ctc.wstx.stax.Ws=
txInputFactory" />
> ...do we want commit this? =20
> (It wouldn't be the first time we've had to put in settings to force Resi=
n to use the XML Library we want because something doesn't work with theirs=
.)
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org