[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [doi-twg] FW: [handle-dev] New version of proxy server
Thanks, Larry.
I didn't know we had support for GET parameters. Might be useful anyway to
also look out for a "hdl" (and possibly also a "doi"?) parameter, so that
one can start supporting structured links using pure querystring format
rather than pathinfo+querystring (and this would restore the GET/POST
symmetry). So the handle could be presented either as a querystring
parameter or as a pathinfo variable, if I understand correctly.
Be a further step towards OpenURL support.
Tony
-----Original Message-----
From: Larry Lannom [mailto:llannom@cnri.reston.va.us]
Sent: 19 November 2002 21:54
To: Hammond, Tony (ELSLON)
Cc: 'doi-twg@doi.org'; 'jeuler@cnri.reston.va.us';
'handle-dev@cnri.reston.va.us'
Subject: Re: [doi-twg] FW: [handle-dev] New version of proxy server
The OpenURL interface is coming. We'll continue to support the
handle?parameters syntax, since that's been around for quite some time now,
but I hope to exercise the new OpenURL spec in this way when it is put
out for trial use.
Thanks for looking at the new version. Point on needing a spec on this is
well taken. All feedback appreciated.
Larry
On Tuesday, November 19, 2002, at 05:10 AM, Hammond, Tony (ELSLON) wrote:
> Forwarding this to the TWG as it affects DOI as well. Lots of good news
> (Tomcat server, redirect to base URL, whitespace trim, GET querystrings,
> etc
> - see original post to hdl-dev) but some questions about querystring
> implementation.
>
> Tony
>
>
> -----Original Message-----
> From: Hammond, Tony (ELSLON)
> Sent: 19 November 2002 10:05
> To: 'Jane Euler'; handle-dev@cnri.reston.va.us
> Subject: RE: [handle-dev] New version of proxy server
>
>
> Is there any spec to show how parameters should be passed in GET
> querystrings? Seems that one must append a querystring to the pathinfo
> variable for the handle, ie something like
>
> http://hdl.handle.net/10.1006/geno?noredirect=on
>
> I would however have expected something more like the following (ie the
> GET
> equivalent of the data POST) to be implemented
>
> http://hdl.handle.net/?hdl=10.1006/geno&noredirect=on
>
> but this does not work. (So seems there is a GET/POST asymmetry.)
>
> Better still would have been an OpenURL (v1.0) interface, ie something
> like
>
>
>
http://hdl.handle.net/?url_ver=Z39.88-2003&rft_id=ori:hdl:10.1006/geno&srv_i
> d=uri:hdl:srv/noredirect
>
> The OpenURL is readily detected (and actioned) as such through the
> mandatory
> version number (value of "url_ver"). The handle is given as the referent
> identifier (value of "rft_id"). Service directives could be included via
> "srv_id" parameters, where individual services would be identified with
> their own handles.
>
> Thanks,
> Tony
>
>
> -----Original Message-----
> From: Jane Euler [mailto:jeuler@cnri.reston.va.us]
> Sent: 18 November 2002 20:07
> To: handle-dev@cnri.reston.va.us
> Subject: [handle-dev] New version of proxy server
>
>
> Hi All:
> The Handle proxy server (hdl.handle.net/dx.doi.org) will be upgraded to a
> new version tonight at approximately 11:30pm EST.
> The new features are listed below.
>
> The amount of downtime will be unnoticeable.
> Please let us know if you experience any problems.
>
> Thanks
> Jane Euler
> CNRI
>
> --------------------------------------
>
>
> o Now based on Apache Tomcat for better extensibility.
> o Will now redirect to the URL value with the lowest index. Previously,
> the
> proxy would redirect to an arbitrary URL in DOIs/Handles with multiple
> URLs.
> o A new parameter "urlappend" allows an opaque character string to be
> appended to the target URL.
> o Whitespace is now trimmed from POST requests. This is useful for when
> handles entered into the query form at hdl.handle.net or dx.doi.org have
> leading or trailing spaces. Previously these spaces were interpreted as
> part of the handle.
> o Handle value data display now shows readable fields for binary types
> like
> HS_ADMIN and HS_VLIST.
> o Parameters passed though POST can also be passed through GET requests.
> This includes parameters such as noredirect, authoritative, types,
> indices,
> etc.
>
>
> _______________________________________________
> handle-dev mailing list
> handle-dev@cnri.reston.va.us
> http://www.cnri.reston.va.us/mailman/listinfo/handle-dev
>
_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev
From handle-dev-admin@cnri.reston.va.us Thu Jan 23 20:21:39 2003
Return-Path: <handle-dev-admin@cnri.reston.va.us>
Received: from www1 by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id UAA08229; Thu, 23 Jan 2003 20:19:45 -0500
Received: from cnri.reston.va.us by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id UAA08201; Thu, 23 Jan 2003 20:19:38 -0500
Received: from jupiter.natlib.govt.nz (jupiter.natlib.govt.nz [210.55.131.76])
by cnri.reston.va.us (8.11.6+Sun/8.11.3) with ESMTP id h0O1JqN15029;
Thu, 23 Jan 2003 20:19:53 -0500 (EST)
Received: from jupiter.natlib.govt.nz (localhost [127.0.0.1])
by jupiter.natlib.govt.nz (8.10.1/8.10.1) with ESMTP id h0O1Jmj27708;
Fri, 24 Jan 2003 14:19:48 +1300 (NZDT)
Received: from planet.natlib.govt.nz (planet.natlib.govt.nz [192.122.171.130])
by jupiter.natlib.govt.nz (8.10.1/8.10.1) with ESMTP id h0O1Jl427698;
Fri, 24 Jan 2003 14:19:47 +1300 (NZDT)
Received: from gwia.natlib.govt.nz (kursk.natlib.govt.nz [210.55.131.57])
by planet.natlib.govt.nz (8.11.1/8.11.1) with SMTP id h0O1Jqg17830;
Fri, 24 Jan 2003 14:19:53 +1300 (NZDT)
Received: from WNDomain-Message_Server by gwia.natlib.govt.nz
with Novell_GroupWise; Fri, 24 Jan 2003 14:22:30 +1300
Message-Id: <se314c26.033@gwia.natlib.govt.nz>
X-Mailer: Novell GroupWise 5.5.4
Date: Fri, 24 Jan 2003 14:19:38 +1300
From: "Lockie Stewart" <Lockie.Stewart@natlib.govt.nz>
To: <jeuler@cnri.reston.va.us>
Cc: <handle-dev@cnri.reston.va.us>,
"Dave Thompson" <dave.thompson@natlib.govt.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Subject: [handle-dev] Hi Jane,
Sender: handle-dev-admin@cnri.reston.va.us
Errors-To: handle-dev-admin@cnri.reston.va.us
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Handle System Developers' Mailing List <handle-dev.cnri.reston.va.us>
X-BeenThere: handle-dev@cnri.reston.va.us
content-length: 1910
Hi Jane,
Seeking a robust handle environment at National Library of NZ leads us to =
install handle servers on two host (tainui and fred)=20
Our dns entry handle.natlib.govt.nz resolves to tainui. (tainui CNAME =
handle.natlib.govt.nz , fred CNAME bogus.natlib.govt.nz)
If we want to change the handle server from tainui to fred we can do so by =
altering the dns entries so that the handle.natlib.govt.nz resolves to =
fred. (tainui CNAME bogus.natlib.govt.nz , fred CNAME handle.natlib.govt.n=
z)
The question therefore becomes : how do we keep the handle databases in =
sync between the two hosts ? In other words is there a file or files that =
we can ftp between servers such that the contents are the same on both of =
the hosts ?
This of course assumes that there is not a master/secondary handle server =
heirarchy reflected on the hosts, that we take it upon ourselves to ensure =
administration of handles occurs on the correct host , and that the =
replication follows.
Regards, Lockie
V V DBA
V V National Library of New Zealand =
=20
\ / Ph 0064 4 4743134 x 8720=20
< .. >___ Mobile 0064 21 648044 =20
U } Fax 0064 4 474 3140 =20
yyyy Pager dba.pager@natlib.govt.nz =20
=
--------------------------------------------------
=20
=
=20
=20
_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev
From handle-dev-admin@cnri.reston.va.us Wed Jan 29 14:59:13 2003
Return-Path: <handle-dev-admin@cnri.reston.va.us>
Received: from www1 by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id OAA26794; Wed, 29 Jan 2003 14:56:59 -0500
Received: from cnri.reston.va.us by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id OAA26765; Wed, 29 Jan 2003 14:56:56 -0500
Received: from abyssus.doit.wisc.edu (abyssus.doit.wisc.edu [128.104.19.201])
by cnri.reston.va.us (8.11.6+Sun/8.11.3) with ESMTP id h0TJvDN14219
for <handle-dev@cnri.reston.va.us>; Wed, 29 Jan 2003 14:57:13 -0500 (EST)
Received: from abyssus.doit.wisc.edu (msimpson@localhost)
by abyssus.doit.wisc.edu (8.11.6/8.11.6) with ESMTP id h0TJx9F32524
for <handle-dev@cnri.reston.va.us>; Wed, 29 Jan 2003 13:59:10 -0600
Message-Id: <200301291959.h0TJx9F32524@abyssus.doit.wisc.edu>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: handle-dev@cnri.reston.va.us
Subject: Re: [handle-dev] Hi Jane,
In-Reply-To: Your message of "Fri, 24 Jan 2003 14:19:38 +1300."
<se314c26.033@gwia.natlib.govt.nz>
Reply-to: mike.simpson@doit.wisc.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 29 Jan 2003 13:59:09 -0600
From: Mike Simpson <msimpson@abyssus.doit.wisc.edu>
Sender: handle-dev-admin@cnri.reston.va.us
Errors-To: handle-dev-admin@cnri.reston.va.us
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Handle System Developers' Mailing List <handle-dev.cnri.reston.va.us>
X-BeenThere: handle-dev@cnri.reston.va.us
content-length: 5782
Lockie et al. --
I'm in the process of trying to set up something similar for the
UW-Madison Libraries handle servers ... replication and automated
failover in the case of the primary server going down. I'm trying to
make sense of the documentation and what I see in the naming
authority handle, and I admit I'm getting stuck. Hopefully others on
this list will have already solved this problem ...
We have a primary server ("handle-1") living at IP 144.92.161.72,
ports 2641 (tcp, udp) and 2652 (http), serving the 0.NA/1711 naming
authority. I want to replicate and failover to a mirror server
("handle-2") living at IP 144.92.161.73 (same port assignments as the
primary).
From looking primarily at Section 10 ("Replication") in the
Administration Manual, and various other bits and pieces, it looks
like two things have to happen:
(a) setup the mirror server and get replication authentication
established. To do this, run the "Simple Setup" as detailed in the
INSTALL file. Answer "n" to the "Will this be a primary server?"
question, then enter the IP and port number of the primary server
when prompted (i.e. for us, 144.92.161.72:2641). The setup program
prompts for a server key (which we don't encrypt, since we have to do
unattended restarts), skips prompting for an administrative key (only
relevant for primary servers), and the prompts for a "replication
authentication" key.
-> question #1: If I choose to encrypt the replication
authentication key, will I need to enter the password at server
startup, or otherwise periodically? I.e. is it more like the
server key, or more like the administrative key?
The program finishes by telling you to email the sitebndl.zip file to
CNRI. They use it to update the HS_SITE information in the 0.NA
handle, I'm guessing (see below).
Then you have to modify the config.dct file in various ways. The
instructions in the Admin Manual seem a little vague to me. You need
to modify "server_admins" ...
-> question #2: What value do I put there? The same as in the
primary, i.e. for us "300:0.NA/1711"?
and "this_server_id" ...
-> question #3: The manual says that you must modify this "if more
than 1 server in HS_SITE". Does a mirror server, running on a
seperate host at a seperate IP, wind up as another entry in a
single HS_SITE record, or as a seperate HS_SITE record entirely?
Do I need to change this number so that it's different from the
primary?
and "replication_authentication" ...
-> question #4: What goes here? The manual doesn't say. The setup
program, for me, filled in "privatekey:300:0.NA/1711". Is this
correct?
Then, the manual says you have to modify the config.dct for the
primary server. These directions are even less clear to me:
-> question #5: I'm supposed to "Add the replication public key
value(`replpub.bin') to the handle specified in
replication_authentication.". My primary doesn't have any
value set for "replication_authentication". And do I need to
copy "replpub.bin" over to the primary server directory?
-> question #6: Then I need to "Add that handle to the primary
server's replication_admins group in its `config.dct' file."
What handle is "that handle"?
-> question #7: There's a step that needs to be done "ONLY if
mirror servers are under the same HS_SITE". Same question as
#3 above; also, the proceeding line in the manual states that
"The `txnsrcsv.bin' file is the `siteinfo.bin' file from the
primary server." Does that mean I have to copy the primary's
"siteinfo.bin" into place under the mirror as "txnsrcsv.bin"?
(b) Once all the above is ready, then we go to what has to happen at the
0.NA (CNRI) end. This is more or less black magic to me, but from
looking at our naming authority handle (0.NA/1711) it looks like
a second HS_SITE record has to be created. I.e. the existing HS_SITE
record has a yes/no value for "Primary Site" for the record as a
whole, although it looks like you could have multiple servers all
participating as your "primary site". From the "Handle System
Namespace and Service Definition", section 3.2.2, it looks like a
"service site" (HS_SITE?) can be one or more server instances running
on one or more hosts; the "<PrimaryMask>" field of the HS_SITE
record specifies whether or not a given HS_SITE is a "primary" (as
opposed to mirror?) as well as whether or not there are multiple
primary sites. Here, "primary" seems to mean "able to do handle
administration tasks".
-> question #8: So for a plain ol' replicated mirror of the 1711
naming authority, does CNRI wind up adding another HS_SITE record
to the 0.NA/1711 handle, with the "<PrimaryMask>" field zeroed
out ("this service site is not a primary, nor are there multiple
primaries under this naming authority")?
This seems to match up with what's defined in the "Handle System
Protocol (ver 2.1) Specification", sections 3.1.2 and 3.1.3. I'm
probably missing it, but I couldn't find anything specified for
client behavior when the primary server is down, under section 3.2.3.
My assumption would be that a "well-behaved" client would pull all of
the HS_SITE records for a given NA, try the first one, then try the
next if the primary is down, etc. Although I can't find that defined
in the protocol document (but I've only scanned it so far, haven't
read the whole thing as of yet).
Anyway ... anyone done this? Am I on the right track, or completely
round the bend? :)
-mgs
_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev
From handle-dev-admin@cnri.reston.va.us Wed Mar 26 07:39:06 2003
Return-Path: <handle-dev-admin@cnri.reston.va.us>
Received: from www1 by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id HAA15182; Wed, 26 Mar 2003 07:33:25 -0500
Received: from ns.cnri.reston.va.us by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id HAA15164; Wed, 26 Mar 2003 07:33:17 -0500
Received: from elslonexc001.epress.co.uk ([194.128.151.2])
by ns.cnri.reston.va.us with esmtp (Exim 4.12)
id 18yA6O-0002NU-00
for handle-dev@cnri.reston.va.us; Wed, 26 Mar 2003 07:33:56 -0500
Received: by elslonexc001.epress.co.uk with Internet Mail Service (5.5.2653.19)
id <HTWA1R7Z>; Wed, 26 Mar 2003 12:33:03 -0000
Message-ID: <54A600C436EA694581B93E4BD4D4788A06B7383B@elslonexc004.wins.epress.co.uk>
From: "Hammond, Tony (ELSLON)" <T.Hammond@elsevier.com>
To: "'handle-dev@cnri.reston.va.us'" <handle-dev@cnri.reston.va.us>
Date: Wed, 26 Mar 2003 12:33:07 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Subject: [handle-dev] OpenHandle
Sender: handle-dev-admin@cnri.reston.va.us
Errors-To: handle-dev-admin@cnri.reston.va.us
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Handle System Developers' Mailing List <handle-dev.cnri.reston.va.us>
X-BeenThere: handle-dev@cnri.reston.va.us
content-length: 2218
For something different - an OpenHandle servlet:
http://hdl.handle.net/1014/open
You should be able to try any legitimate handle, eg
* for Elsevier handle service (1014)
1014/oboe
1014/yads
1014/1
* for DOI handle service (10)
10.1006/geno
10.1016/S0888-7543(03)00007-7
10.1000/240
* for Global handle service (0) - the most interesting
0.serv/10
0.na/10
(service and naming authority handles for DOI)
Tony
A few rough edges here and there but anyway. What is it?
* A simple declarative means for a user to interact with handle
* Uses the ANSI/NISO OpenURL Framework to query handle and
receive back a structured XML response. (OpenURL drafts posted
at <http://library.caltech.edu/openurl/Public_Comments.htm>)
* Alternate responses could include resolution to stored URI,
service referral, etc
* OpenURL Framework allows contextual information to be bundled along
with the query/response messaging
* An RDF schema (using OWL) is defined for the ContextObject Format
of the OpenURL Framework
* A handle is given as an OpenURL Referent Identifier - the full
handle record is then returned as Referent Private Data
* An RDF Schema is defined for a handle record - supports the
predefined handle types HS_ADMIN, HS_SITE, HS_SERV, HS_PRIMARY,
HS_ALIAS, HS_VLIST
* Service data is passsed up as ServiceType Identifiers (for service
directives - eg authoritative query, etc) or as ServiceType
Metadata (service filtering - on index/type), and is passed back
as ServiceType Private Data (service messages)
* Controversial point - handle references are given compactly in
handle URIref form - eg <hdl://0.NA/1006#index=200> indicates
the handle value at index 200 for the handle 0.NA/1006
* Handle URIref form is how a handle client would address into a
handle resource - suggest that an alternate means of filtering
handle values is to use a fragment identifier syntax, eg
<#index=2;type=url> to return values of type URL at index 2
* In sum - Resource Description Framework over OpenURL Framework
_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev