[OAI-implementers] Should OAI-PMH over HTTPS be permitted?

Patrick Hochstenbach Patrick.Hochstenbach at ugent.be
Thu Feb 17 11:06:19 EST 2005

A related issue: if Static Repository Files would also be accessible via
HTTPS, then constructing a OAI-PMH Gateway would be problematic because
gateways URL's don't contain the scheme of the original file location. 


I don't know if other types of gateways have the same problems.

Patrick Hochstenbach

On Thu, 17 Feb 2005, Thomas G. Habing wrote:

> Hussein Suleman wrote:
>>  > Which harvesters could not easily support HTTPS?
>> mine :) anything i distribute is meant to be as "dependency-free" as 
>> possible. historically, LWP has not been the easiest module to get working 
>> on a variety of architectures, so i don't use it.
>> if we require every harvester to support HTTPS, this will become the first 
>> feature that programmers will need to support through external code 
>> libraries. as such we will raise the "low barrier to entry" substantially.
>> i agree we should explicitly support HTTPS, but not require it.
> Because of the underlying APIs that we use (WinHTTP and MSXML), the harvester 
> that we use at UIUC supports HTTPS.  I agree with Hussein that harvesters 
> should be explicitly encouraged to support HTTPS, but it should not be a 
> requirement of the protocol.
> Maybe some advice on this topic could be added to the "Implementation 
> Guidelines" documents.
> Kind regards,
> 	Tom Habing
>> ttfn,
>> ----hussein
>> Simeon Warner wrote:
>>> There has been some interest recently in using OAI-PMH over HTTPS [1]. The
>>> OAI-PMH specification [2] mentions only operation over HTTP, so I think
>>> that at present HTTP must be used to conform to the specification (and
>>> this is enforced by the validation/registration site). The specification
>>> should be explicit about whether the use of HTTPS is conforming or not.
>>> It would be trivial to extend the specification to permit the use of HTTPS
>>> as it is just standard HTTP operating over an additional security layer.
>>> There would be no need to change the semantics or syntax beyond the
>>> substitution of 'https://' for 'http://'. Permitting HTTPS would have no
>>> implications for data-providers unless they wished to use the protocol.
>>> The main implication of permitting HTTPS would be that harvesters would
>>> have to support HTTPS in addition to HTTP (or else be unable to harvest
>>> from some data-providers). In many programming environments there are
>>> libraries that provide seamless support for both HTTPS and HTTP (e.g. in
>>> Perl, HTTPS comes for free in LWP) but this may not be true in all cases.
>>> Who is using or would like to use HTTPS?
>>> Which harvesters already support HTTPS or could easily do so?
>>> Which harvesters could not easily support HTTPS?
>>> Cheers,
>>> Simeon
>>> [1] http://www.isi.edu/in-notes/rfc2818.txt
>>> [2] 
>>> http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm#HTTPembedding 
>>> ----------------------------------------------------------
>>> Simeon Warner                 Email: simeon at cs.cornell.edu
>>> Cornell Information Science              Tel: 607-254-8605
>>> 301 College Ave                          Fax: 607-255-5196
>>> Ithaca, NY 14850-4623, USA
>>> _______________________________________________
>>> OAI-implementers mailing list
>>> List information, archives, preferences and to unsubscribe:
>>> http://www.openarchives.org/mailman/listinfo/oai-implementers

More information about the OAI-implementers mailing list