http access, was Re: DTDs and such

[Andy Heninger <an...@jtcsv.com>]

OK, there is improved access by the scanner to
documents via http, code is now in CVS.

The problematic http://www.wapforum.org/DTD/wml_1.1.xml.
is now working.

But this code could really stand to be beefed up.  It
doesn't do HTTP 1.1, it doesn't do redirection, it doesn't
do proxies, it ignores almost everything from the
http header except for the "200 OK" response, error checking
is questionable.  An already existing library for this
would be nice, but I haven't seen one besides libwww.
And that has its own set of problems, which is why it
isn't being used here already.

An item for the (soon to be posted) to-do list.

Andy Heninger
IBM XML Technology Group, Cupertino, CA
heninger@us.ibm.com



----- Original Message -----
From: "Andy Heninger" <an...@jtcsv.com>
To: <xe...@xml.apache.org>; <db...@aego.com>
Sent: Wednesday, July 19, 2000 5:30 PM
Subject: Re: DTDs and such


> It turns out that there are a couple of problems in the http
> accessing code in the parser.  I'll try to get a fix in for it.
>
> The problem is not with the content-types returned, but with the
> http requests being issued.
>
> If anyone has already fixed this on the side, now would
> be a good time to send in the changes.
>
> Andy Heninger
> IBM XML Technology Group, Cupertino, CA
> heninger@us.ibm.com
>
>
>
> ----- Original Message -----
> From: "Drew Besser" <db...@aego.com>
> To: <xe...@xml.apache.org>
> Sent: Monday, July 17, 2000 7:27 PM
> Subject: DTDs and such
>
>
> > Hi Folks,
> > We are parsing and validating WML pages on the fly and seem to be
having
> a
> > little trouble verifying a DTD via HTTP using the xerces-c SAX Parser.
> > Particularly, I've been using a modification of MEMParse and SAXPrint.
> > Anyways, the WML DTD that we use, found at:
> > http://www.wapforum.org/DTD/wml_1.1.xml. When I run a valid WML file
> > referencing this DTD through SAXPrint, i get the error: "expected a
> mark-up
> > declaration." When I run the same DTD on my local server, I get no
such
> > error. On comparing the two headers I receive from each server, the
line
> > that differs is this:
> > wapforum gives me a content-type: text/plain
> > and my server gives content-type: text/xml.
> >
> > I'm assuming that the program doesn't require an xml markup
declaration
> if
> > it knows the content type is already xml. Where in the source code can
I
> > tweek so that it doesn't require an XML markup ever? I've tried
digging
> > through XMLHTTP and DTDVALIDATOR2 to no avail.
> >
> > ANy help would be greatly appreciated
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>

Re: http access, was Re: DTDs and such

[James Berry <jb...@criticalpath.com>]

I just finished tonight a NetAccessor class for the Mac port that uses
Apple's URLAccess routines to provide http, https, and ftp transactions, and
relatively robust handling thereof. It was great to have a stable library of
http code to build upon. Am I right in remembering that there's something
similar that can be leveraged under Windows? Or is that just MFC classes?

I'll submit my code after it's had a bit more of a shakeout.

-jdb

Andy Heninger wrote:

> OK, there is improved access by the scanner to
> documents via http, code is now in CVS.
>
> The problematic http://www.wapforum.org/DTD/wml_1.1.xml.
> is now working.
>
> But this code could really stand to be beefed up.  It
> doesn't do HTTP 1.1, it doesn't do redirection, it doesn't
> do proxies, it ignores almost everything from the
> http header except for the "200 OK" response, error checking
> is questionable.  An already existing library for this
> would be nice, but I haven't seen one besides libwww.
> And that has its own set of problems, which is why it
> isn't being used here already.
>
> An item for the (soon to be posted) to-do list.