[jdom-interest] end-of-line character

[Elliotte Rusty Harold]

>Elliotte, out of curiosity, can you explain how a document with \n
>endings is going to confuse the HTTP protocol, considering on both
>upload and download the document is treated as raw data and not as
>anything a server or proxy program itself will be parsing?
>

This isn't going to happen with any reasonable, high-quality Web 
server like Apache or IIS. These all handle non-standard-conformant 
clients with aplomb. But it happens all the time with web servers and 
clients (as well as other network servers and clients) hacked 
together by inexperienced network programmers.

Sometimes it takes a combination of several bugs to really cause the 
problem. The worst combination is when a Mac client is using 
PrintStream or PrintWriter to communicate with a server written in 
Java that's using readLine() or vice versa. The readLine() method has 
some nasty bugs in it, that only get exercised when it faces a 
network connection that's terminated with carriage returns. In 
particular, the problem arises when the last character of a stream is 
a carriage return and there's no end of stream marker (-1) 
forthcoming. (This can happen in any protocol that doesn't require 
the sender to close the connection after it's sent the last byte; as 
in HTTP Keep-Alive, for example.) This one pops up on the mrj-dev 
(Macintosh Java) mailing list at least once a month, but I suspect 
the real problem is more frequent since somebody who's developing on 
Unix or Windows may not realize certain Mac clients are hanging when 
they connect.

What's most insidious about this problem is that it is rare. 99% of 
the time you're not going to run into it, since several things need 
to go wrong at once. However, when they do all go wrong at once (and 
they do) it's really hard to track down if you don't already know the 
answer.

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

Received: from gvmail01.epo.org ([145.64.128.100])
	by dorothy.denveronline.net (8.9.3/8.9.3) with ESMTP id HAA17386
	for <jdom-interest at jdom.org>; Fri, 7 Jul 2000 07:13:15 -0600 (MDT)
Received: from gvmail02.th.epo.nl (unverified) by gvmail01.epo.org
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc0a83264824d428ddb12 at gvmail01.epo.org> for <jdom-interest at jdom.org>;
 Fri, 7 Jul 2000 14:44:34 +0200
Received: from epo.org ([172.16.33.217]) by gvmail02.th.epo.nl
          (Netscape Messaging Server 3.62)  with ESMTP id 379
          for <jdom-interest at jdom.org>; Fri, 7 Jul 2000 14:47:47 +0200
Message-ID: <3965D1B2.65D6A6A7 at epo.org>
Date: Fri, 07 Jul 2000 14:48:50 +0200
From: Andre Van Delft <avandelft at epo.org>
Organization: European Patent Office
X-Mailer: Mozilla 4.7 [en-gb] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: jdom-interest at jdom.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [jdom-interest] NoSuch*Exceptions in JDOM
Sender: jdom-interest-admin at jdom.org
Errors-To: jdom-interest-admin at jdom.org
X-BeenThere: jdom-interest at jdom.org
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: JDOM Mailing List for General Issues and Updates <jdom-interest.jdom.org>

In some cases I want a NoSuch*Exception, when a child or attribute must
be present.
In some cases the child or attribute is optional; then I want null
returned since there is no exceptional situation, and my code should be
simple.

We can have it both ways.
I use a util function getChild that returns a null if the child is
absent.
I prefer the Element.getChild function to behave like this.
The old Element.getChild functions throwing the exceptions may well be
renamed into mustGetChild.
That would do, IMHO.