search

OParl / spec

Spezifikation für eine offene Schnittstelle für Ratsinformationssysteme
https://oparl.org
Creative Commons Attribution Share Alike 4.0 International
61 stars 21 forks source link

HTTP und HTTPS #90

Closed marians closed 10 years ago

marians commented 10 years ago

Ich gehe davon aus, dass die Mehrheit der Server-Anbieter die OParl-Schnittstelle über HTTP (unverschlüsselt) anbieten möchte. Falls ein Server jedoch unter HTTPS laufen soll, sehe ich keinen Grund, der dagegen spricht.

Allerdings sehe ich für diesen Fall mehrere zusätzliche Bedingungen bzw. Empfehlungen.

  1. Der Server MUSS entweder auf HTTP oder auf HTTPS antworten.
  2. Wenn der Server regulär Anfragen über HTTPS beantwortet, DARF er über HTTP NICHT zusätzlich auch noch reguläre Anfragen beantworten. Anfragen auf unverschlüsseltem HTTP MÜSSEN in dem Fall mit einem Redirect (Status Code 301 oder 302) auf die entsprechende HTTPS-URL beantwortet werden.
  3. Punkt 2 gilt auch umgekehrt. Antwortet der Server regulär auf HTTP, dann MÜSSEN Responses auf HTTPS lediglich dem Zweck der Weiterleitung dienen.

Diese Regeln in 2 und 3 dienen dazu, doppeldeutige URLs zu vermeiden, die letztlich den selben Inhalt anbieten. Also beispielsweise

https://meinris.de/papers/123
http://meinris.de/papers/123

Wem noch weitere Anforderungen zu HTTP oder HTTPS einfallen, bitte hier kommentieren.

akuckartz commented 10 years ago

Die Frage ist auch insoweit wichtig, als die beispielhaften IRI (mit bzw. ohne das "s") von sich aus auch im RDF-Sinne nicht identisch sind. Man kann solche Zwillinge zwar mit owl:sameAs für identisch erklären, aber diese Verdopplung ist insgesamt kaum eine Vereinfachung.

Ich bin aus Datenschutzgründen für https als SOLL-Anforderung.

marians commented 10 years ago

Welche Daten soll HTTPS denn schützen? Welche URLs ein Client abfragt?

bschalitz commented 10 years ago

Dann vielleicht nur http. Da die Inhalte öffentlich sind.

Könnte man im json auch URL's ohne Protokoll verwenden oder entspricht das dann irgendeiner anderen geforderte Spezifikation nicht mehr.

akuckartz commented 10 years ago

@marians Genau. Je nachdem was für ein IRI das ist, kann das schon relevant sein. Es ist auch egal, ob das nur bei einem kleinen Teil der IRIs so ist. Das gilt insbesondere (aber eben nicht nur) falls auch Suchworte o.ä. übertragen werden.

@bschalitz Nein, URLs (IRIs) müssen für JSON-LD das Schema enthalten (deshalb übrigens auch "mailto:" vor mail-Adressen!) EDIT Zur Präzisierung: das gilt natürlich nur für das expanded Format.

marians commented 10 years ago

@akuckartz Laut http://www.w3.org/TR/json-ld/#base-iri können IRIs auch in einer relativen Form angegeben werden. In dem Fall haben sie kein Schema. Aber das Schema ergibt sich aus der in "@base" angegebenen IRI.

akuckartz commented 10 years ago

@marians Sorry, ja, ich ging bei der Antwort von der expandierten Form aus. Je nachdem, was im context steht, muss man als relative Angabe noch nicht einmal eine Domain angeben.

akuckartz commented 10 years ago

Aus "LDP Best Practices and Guidelines":

"2.10 Respond with canonical URLs and use them for identity comparison

Clients can access an LDPR using multiple URLs. An LDPR server should respond to each of those requests using a single consistent URL, a canonical URL, for the LDPR. This canonical URL may be found in the response's Location and/or Content-Location headers, and potentially also in the representation of the LDPR. A common case is URLs that vary by protocol, one HTTP and one HTTPS, but are otherwise identical. In most cases those two URLs refer to the same resource, and the server should respond to requests to either URL with a single (canonical) URL.

Clients should use the canonical URL as an LDPR's identity; for example, when determining if two URLs refer to the same resource clients should compare the canonical URLs, not the URLs used to access the resources." https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html#respond-with-canonical-urls-and-use-them-for-identity-comparison

marians commented 10 years ago

Die Empfehlung deckt sich nach meinem Verständnis mit der Empfehlung, die ich weiter oben beschrieben habe:

Der RIS-Betreiber muss sich für HTTPS oder HTTP als kanonische Form entscheiden. Dies sollte sich dann darauf auswirken, welches Schema (Protokoll-Präfix wie "http://" oder "https://") bei der Ausgabe aller IRIs vorangestellt wird und ob wohin ggf. ein Redirect durchgeführt wird (das ist es jedenfalls nach meinem Verständnis, was mit dem Response header "Location" oder "Content-Location" im vorigen Kommentar gemeint ist).

marians commented 10 years ago

Ergebnis des Workshops: Wir empfehlen HTTPS.

marians commented 10 years ago

Ist soweit im Dokument enthalten und wird daher geschlossen.