404 on ce_download/-s

[asaage]

shouldn't the download/-s Elements fire a 404 if the file-parameter is not valid?

Reason is: google indexed some downloads which the customer now deleted because they are obsolete but the google-SeachConsole refuses to kick them out of the index because they still respond with 200.

try the following:

http://demo.contao.org/en/file-elements.html?file=files/contaodemo/media/content-images/DSC_5276.jpg -> 200

http://demo.contao.org/en/file-elements.html?file=files/contaodemo/media/content-images/DSC_5276invalid.jpg -> 200

Im not shure what the best-practice is when handling invalid get-parameters though.

[leofeyer]

shouldn't the download/-s Elements fire a 404 if the file-parameter is not valid?

Nope: #4632, #5683 and #5178.

[fritzmg]

@leofeyer in all diesen Fällen geht es aber nicht darum, ob die Datei überhaupt existiert. Auch in #5178 ging es nicht darum, ob die Datei generell existiert, sondern nur darum, ob die angeforderte Datei in der Liste der selektierten Download Dateien ist. Da musste das Senden des 404 headers entfernt werden, und das ist auch ok.

Das hat aber noch nichts damit zu tun, ob die Datei generell existiert. In so einem Fall sollte ein 404 header gesendet werden. Und soweit ich das sehe, würde das in keinem der genannten Fälle ein Problem machen.

[fritzmg]

Ganzheitlich würde dies das Problem aber dennoch nicht lösen. Angenommen man entfernt das Download(s) Inhaltselement wieder von einer Seite, dann würden URLs mit ?file=… wiederum keinen 404 header senden.

[leofeyer]

Eine mögliche Lösung wäre es, einen Event-Listener auf kernel.response zu registrieren, der bei Vorhandensein des ?file= parameters eine 404-Exception wirft. Wenn die Datei existiert, würde bereits vorher eine File-Response geschickt.

@contao/developers /cc

[Toflar]

Ich finde nicht, nein. Ein 404 ist für eine Seite die nicht gefunden wurde und hat nichts mit einem behandelten oder nicht behandelten Query-Parameter zu tun. Wenn der Query-Parameter nicht passt, soll er einfach ignoriert werden, das ist in meinen Augen das absolut richtige Verhalten. Ich will definitiv keinen 404 hier.

[asaage]

Wenn der Query-Parameter nicht passt, soll er einfach ignoriert werden

So kenne ich das für gewöhnlich auch.
Ich hatte deshalb auch schonmal mit dem Gedanken gespielt anstelle der Links mit query-parameter post-forms zu verwenden.
Das würde nochmal andere Möglichkeiten ins Spiel bringen (z.B. wirkliche Verhinderung von Hotlinking oder Zusammengefasster Download von ce_downloads als zip-Datei)
Wie gesagt - war nur ein Gedankenspiel, was ich aus verschiedenen Gründen wieder verworfen hatte aber vielleicht kann man's doch nochmal aufgreifen.

[fritzmg]

Oder man macht es in Zukunft als URL Parameter? Also zB. wenn auf der Seite foo.html ein Download Inhaltselement ist und man dann Dateien per foo/file/DSC132456.jpg runterladen kann - ist aber nicht so leicht in Contao möglich, schätze ich.

[ausi]

Eine mögliche Lösung wäre es, einen Event-Listener auf kernel.response zu registrieren, der bei Vorhandensein des ?file= parameters eine 404-Exception wirft.

Ich denke nicht, dass das optimal wäre. Was ist wenn ich auf einer Seite den file-Parameter für etwas anderes benutze?

[Toflar]

So seh ich das auch. Das wirkliche Problem liegt darin, dass das Inhaltselement nicht bestimmen kann, ob es zuständig ist oder nicht. Das kann man mit z.B. einem '&cid=42' umgehen.

[leofeyer]

Also z.B. ?file=foo.pdf&cid=42?

[Toflar]

Ja, das scheint mir irgendwie logisch. Wenn ich einen Ajax-Request erwarte muss ich ja auch irgendwie feststellen ob ich gemeint bin, das ist hier nicht anders.

[leofeyer]

Wir sollten hierüber nochmal diskutieren, denn die Lösung mit dem cid=42 ist ein BC-Break IMO. Alle bisherigen Download-Links würden dadurch ungültig.

[fritzmg]

Bei nicht vorhanden sein des cid Parameters, würde doch einfach nur das alte Verhalten wieder da sein, oder nicht? Also zB

if (!\Input::get('cid') || \Input::get('cid') == $this->id)
{
    …
}

[leofeyer]

So könnte man es implementieren, aber das würde das oben angesprochene Google-Problem ja nicht lösen.

[fritzmg]

Naja, für alte URLs nicht. Für neue URLs kann das spezifizierte Inhaltselement ja dann den 404 Header senden.

// soll jetzt überhaupt ein 404 Header gesendet werden in so einem Fall?

[leofeyer]

Initiale Problembeschreibung:

Reason is: google indexed some downloads which the customer now deleted because they are obsolete but the google-SeachConsole refuses to kick them out of the index because they still respond with 200.

[asaage]

what about something like that?

<div class="ce_download">
  <form method="post">
     <input type="hidden" value="filerefence">
     <input type="hidden" value="cid">
     <input type="submit" value="filename size etc..">
  </form>
</div>

and on submit pass the download as stream.

It would shurely be a BC Break too but this approach would work with no queryParameters at all and it prevents google or other sites to link to the file directly. (if you want that you could still use ce_hyperlink with the filepicker)

[bekanntmacher]

Kann man nicht den 200er lassen und:

• ein canonical zu http://demo.contao.org/en/file-elements.html setzen
• oder die Seite noindex,follow setzen

[asaage]

In diesem Zusammenhang ist mir noch aufgefallen, dass der Browser einen anderen mime-type erwartet als er bekommt. Ist zwar nicht weiter dramatisch aber vielleicht lässt sich das in Folgeüberlegungen miteinbeziehen. Für mich wäre das ein weiters Indiz, dass die Lösung mit Queryparametern nicht ganz astrein ist.

[leofeyer]

Bei nicht vorhanden sein des cid Parameters, würde doch einfach nur das alte Verhalten wieder da sein, oder nicht? Also zB

if (!\Input::get('cid') || \Input::get('cid') == $this->id)
{
   …
}

Wie am 12. April auf Mumble besprochen, wollen wir diese Lösung, selbst wenn sie das Problem nur für zukünftige und nicht für bestehende URLs lösen kann.

[leofeyer]

Implementiert in contao/core-bundle@399bfe6.