[OAI-implementers] Should OAI-PMH over HTTPS be permitted?
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.
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
>> Simeon Warner wrote:
>>> There has been some interest recently in using OAI-PMH over HTTPS . The
>>> OAI-PMH specification  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?
>>>  http://www.isi.edu/in-notes/rfc2818.txt
>>> 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:
More information about the OAI-implementers