RE: Basic Authentication with Document(), import,or include

[Christopher Ebert]

Title: RE: Basic Authentication with Document(), import,or include

 

    Hi Joe,

 

    I've got a URIResolver, of course -- unfortunately, it uses enough other objects/interfaces that I wrote that I'm not sure it's a good example (see attached). The authentication (and many others things) are in the other classes. The gotchas I found:

    1) building from different objects gives different behavior: if you're building from File objects, the 'base' passed in is always set. If you're building from 'stream' objects (InputStream...) then you have to be sure to set the SystemId on the Source yourself.

    2) Not all 'import' or similar constructs get resolved at 'compile' time: some resolve when the template is invoked, so you have to set the URIResolver on the TransformerFactory *and* on the Transformer -- in my case, it's the same resolver.

 

    I started out by implementing a URIResolver that just returned 'null' (that makes Xalan do it's 'default' resolution) and watching the parameters until it started making sense.

 

    Chris

 

-----Original Message-----
From: Simko, Joe [mailto:[EMAIL PROTECTED]
Sent: Monday, July 28, 2003 3:55 PM
To: [EMAIL PROTECTED]
Subject: RE: Basic Authentication with Document(), import,or include

        Boy...you are a bundle of Good news. I was hoping this not to be the case, and that the needs of the community would have redefined or expanded the definition of the HTTP URL(especially with web services becoming more popular). Kudo's on finding that RFC URL reference, I found a similar (almost exact) reference dated in the year 2000 on the Sun web site. If Sun is adhering to this standard, then it would make sense that all the Transform Engines built on their TraX API would not be able to properly resolve the //<user>:<password>@<host>:<port>/<url-path> Syntax. It is interesting that the Transformers accept the syntax to the degree of parsing it after the '@', and attempting to connect to the server. (hence the 401 authentication error) You'd figure they would go the extra step, and support Basic Authentication in the URL. Guess in a way they do by giving you the option of selecting a different URIResolver, you just have to build it.

        Got any hints on where to find sample source to build a URI Resolver? Man, I hate to have to go there...C'est la vie

-----Original Message-----
From: Christopher Ebert [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 28, 2003 6:17 PM
To: [EMAIL PROTECTED]
Subject: RE: Basic Authentication with Document(), import,or include

Oops. Previous reply didn't go to the list.

Also: the RFC for URLs seems a little unclear, but I think it says that the user:password syntax is *not* a part of the standard HTTP URL. http://www.w3.org/Addressing/rfc1738.txt. On the one hand it says:

3.1. Common Internet Scheme Syntax

   While the syntax for the rest of the URL may vary depending on the
   particular scheme selected, URL schemes that involve the direct use
   of an IP-based protocol to a specified host on the Internet use a
   common syntax for the scheme-specific data:

        //<user>:<password>@<host>:<port>/<url-path>

And on the other:

3.3. HTTP

   The HTTP URL scheme is used to designate Internet resources
   accessible using HTTP (HyperText Transfer Protocol).

   The HTTP protocol is specified elsewhere. This specification only
   describes the syntax of HTTP URLs.

   An HTTP URL takes the form:

      http://<host>:<port>/<path>?<searchpart>

   where <host> and <port> are as described in Section 3.1. If :<port>
   is omitted, the port defaults to 80.  No user name or password is
   allowed.  <path> is an HTTP selector, and <searchpart> is a query
 

Anyway, so far as I can tell you have to set the authentication headers by other means. I implement a URIResolver that makes the http request and sets the headers on it.

Cheers

Chris

URLDirectoryResolver.java
Description: URLDirectoryResolver.java