Dokumentenabruf via URL about spec HOT 16 CLOSED

Reicht es dazu nicht, wenn schlicht auf http://tools.ietf.org/html/rfc2616 verwiesen wird?

from spec.

Dieses Thema ist nach unserer Phasen-Einteilung ab dem 20. Mai relevant.

@akuckartz Das reicht aus meiner Sicht nicht aus. Wenn wir für den Dokumentenabruf (=Download) den gesamten Funktionsumfang des HTTP-Standards zur Verfügung stellen, mit allen darin enthaltenen KANN und MUSS Definitionen, könnten wir die gleichen Probleme wieder bekommen, die bei aktuellen RIS-Implementierungen schon vorliegen. Da gibt es beispielsweise Systeme, wo die Downloads nur durch Absenden eines Formulars (POST) mit übergabe von Tokens und Cookies und einer gültigen Session als Voraussetzung funktionieren.

Ziel soll sein, den Dokumentenabruf einfach, interoperabel, performant und ressourcensparend bewerkstelligen zu können. Dabei sollen die Metadaten eines Dokuments, zu denen auch die Download-URL gehört, über längere Zeit beim Client gespeichert werden können. Das bedingt, dass sich die Download-URL idealerweise nie ändert.

Darüber hinaus werden wir weitere Anforderungen hervorheben, die der HTTP-RFC als optional deklariert.

Beispielsweise möchte ich den Antwort-Header "Last-modified" als verpflichtend vorschlagen. Dazu passend sollten "Conditional Get" Abfragen anhand des Änderungsdatums ("If-modified-since") verpflichtend unterstützt werden.

Außerdem können wir in diesem Zusammenhang über "Content-disposition" Header diskutieren und darüber, ob sie die User Experience verbessern oder schädigen. Ggf. könnten wir diesen Header per Standard ausschließen.

from spec.

Aus meiner Sicht ok, wenn auf rfc2616 verwiesen wird und zusätzliche Eigenschaften gefordert werden. Das finde ich besser als große Teile zu kopieren bzw. kleine Teile (wie "307 Moved Temporarily") zu kopieren und dann aber große Spezifikationslücken zu lassen. Ich vermute sogar, dass es bereits eine solche Spezifikation gibt die unsere Anforderungen fast oder vollständig erfüllt. Wenn ich auf etwas stosse poste ich es.

(Auch wenn das noch nicht relevant war :-)

from spec.

Wichtig ist aus meiner Sicht, dass der Abruf des Dokuments mittels HTTP GET möglich sein MUSS. Redirects sind da selbstverständlich nicht ausgeschlossen.

from spec.

Idealerweise müssen wir hier keine OParl-spezifischen Anforderungen entwickeln. Eine entscheidende Anforderung besteht möglicherweise in der Dereferenzierbarkeit der URIs. Ich schaue für Mittwoch nach Standards oder anderen Dokumenten, auf die verwiesen werden kann. Die können dann zumindest eine Diskussionsgrundlage sein.

from spec.

Workshop: last-modified ist MUST.

from spec.

Workshop: "Content-disposition" ist SHOULD.
MIME-Type als Hinweis.

from spec.

Durch Ausprobieren ist mir gerade klar geworden, dass der "Content-Disposition" HTTP-Header (mit attachment; filename="...", darum ging es ja hier) eine ungünstige Nebenwirkung hat - je nachdem, was man als Nutzer erreichen möchte.

Als Nutzer bin ich es durchaus gewöhnt und finde es auch sehr praktisch, wenn ich einen Link zu einem JPEG-Photo oder einem PDF-Dokument direkt in dem Browser aufrufen kann, in dem ich diesen Link anklicke. So kann der Browser die Datei direkt anzeigen, falls er dazu in der Lage ist. Sonst kann das Öffnen einer geeigneten Anwendung initiiert werden.

Das alles (direktes Öffnen) funktioniert aber nicht, wenn der Content-Disposition Header mit "attachment" gesetzt ist. Dann wird nämlich die Datei direkt gespeichert.

Ich spreche mich daher dafür aus, zwei verschiedene URLs am Dokument vorzusehen. Die eine, nennen wir sie "access_url", dient dem herkömmlichen Zugriff ohne Content-Disposition Header. Die zweite, "download_url", führt zum Aufruf der Datei mit Content-Disposition Header. access_url ist ein MUST, download_url ein SHOULD.

from spec.

Beispiel: http://refserv.oparl.de/bodies/0/papers/0/documents/2

from spec.

Für "Content-Disposition" gibt es laut RFC 6266 (http://tools.ietf.org/html/rfc6266) zwei Disposition Types: Attachment und Inline. Was passiert bei Weglassen von 'attachment;' bzw. mit 'inline; filename="..."' ? (Das sollte genau den erwünschten Effekt haben.)

from spec.

In diesem Zusammenhang sollte auch auf die Verwendung von http Content-MD5 eingegangen werden. Das ist ein "MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body":
http://tools.ietf.org/html/rfc2616#page-121

from spec.

Die Mehrheit dieses Issues (bis hier hin) ist nun mit cadebb8 bzw. einem nachfollgenden Korrektur-Commit ausformuliert. Noch offen:

• Content-MD5
• Last-modified als MUSS-Anforderung

Ich arbeite jetzt noch weiter daran.

from spec.

Last-modified als MUSS-Anforderung ist nun auch drin. Nun ist nur noch Content-MD5 offen, was ich wegen des Aufwands erst mal nicht anpacke. Wir haben übrigens im oparl:Document Objekt die Empfehlung, eine SHA1-Prüfsumme auszuliefern. Die erfüllt den selben Zweck.

from spec.

Verschoben in Milestone "Ferne Zukunft"

from spec.

Ich habe mir für OpenGovLD#91 die Verwendung des Content-Disposition-http-Header (und die Diskussion hier) noch einmal angesehen und sehe keinen Sinn mehr darin, dies zu unterstützen oder auch nur durch SHOULD zu fordern. Eine einzige URL reicht, wenn deren letzter Pfad-Bestandteil einen brauchbaren Dateinnamen enthält. Entsprechend ist dies nun für OpenGovLD geplant.

from spec.

Gelöst in Kapitel 2.7 „Dateizu­griffe“

from spec.