Error 404 mit TIdHTTP

[Maekkelrajter]

Ich habe ein Programm (-Feature) entwickelt, mit dem man von Spotify Metadaten von Playlisten übernehmen kann. Zu diesem Zweck verwende ich in der Spotify - 'Desktop-App' den 'Playlistlink', den Spotify für jede Spotify-Playlist bereithält, und den man per Kontextmenu ('Teilen') in die Zwischenablage kopieren kann. Beispiel: https://open.spotify.com/playlist/62...QBywe0iATNWRxA
Aus dem Quelltext der damit verlinkten Seite entnehme ich die Links zu den einzelnen Tracks, wo ich dann die gesuchten Daten incl. Albumcover finde. Das funktionierte bisher alles einwandfrei. Seit ein paar Tagen jedoch bekomme ich völlig überraschend eine EIdHTTPProtocolException:'HTTP/1.1 404 Not Found' - Exception.
So sieht der Aufruf aus:

Delphi-Quellcode:

     //  IdHTTP1: TIdHTTP;
     //   HTMLSource: String;
     //   FActualClip: String;   (enthält den aktuellen (Text-) Inhalt der Zwischenablage)        

      try
         HTMLSource := IdHTTP1.Get(FActualclip);                                                                           // Quelltext der Playlist- oder Album-Seite laden
      except
         On E:Exception do
         messageDlg(Format('Die Seite %s konnte nicht geladen werden.'#13#10#13#10 +
                                            '(%s:''%s'')',[FActualClip,E.ClassName,E.Message]),
                                            mtError,[mbOK],0);
      end;

Alle Properties von IdHTTP1 enthalten die Defaultwerte, nur 'HandleRedirects' habe ich auf true gestetzt.
Mit dem Albumlink (z.B. https://open.spotify.com/album/3OyRQ...RRuSLlhIYsBE9g) oder einer Liste von Songlinks, die ins Clipboard kopiert werden können, wenn ich mehrere Tracks einer Playlist markiert habe, funktioniert es nach wie vor fehlerfrei. Auch mit dem 'Code zum Einbetten', aus dem ich nur die URL verwende, klappt es zum Glück, womit eigentlich ein perfekter Workaround zur Verfügung steht.
Trotzdem interessiert mich, warum die bewährte Routine plötzlich nicht mehr funktioniert.
Auch interessant: Wenn ich den Playlist-Link in Firefox oder MS Edge eingebe, wird die Seite gefunden, nicht jedoch vom MS IE11 oder Mozilla Seamonkey.
Leider habe ich auf dem Gebiet der Web-Programmierung nur sehr wenig Ahnung. Kann mir irgendjemand einen Tipp geben, wo ich da suchen muss, bzw. wo ich weitere Informationen zum Thema finde?

Gruß LP

[Gausi]

Hat sich evtl. der Aufbau der Seite verändert, so dass deine Methode zum Finden der einzelnen Links jetzt ungültige URLs liefert?

Das ist zumindest meistens der Grund für Fehler in der Lyric-Suche in meinem Player. ;-)

[Delphi.Narium]

Wenn ich im Browser auf https://open.spotify.com/ gehe und dort dann irgendeinen Link klicke, der 'ne Url in der Form

Delphi-Quellcode:

'https://open.spotify.com/playlist/'

enthält, erhalte ich häufig Sorry, couldn't find that., als HTTP-Code also 404.

Haben die da ein Problem und nicht Du?

[Maekkelrajter]

Zitat:

Zitat von Gausi (Beitrag 1472501)

Hat sich evtl. der Aufbau der Seite verändert, so dass deine Methode zum Finden der einzelnen Links jetzt ungültige URLs liefert?

Das ist zumindest meistens der Grund für Fehler in der Lyric-Suche in meinem Player. ;-)

Die Seite wird ja garnicht erst gefunden! Das ist ja das Problem!

Zitat:

Zitat von Delphi.Narium (Beitrag 1472505)

Wenn ich im Browser auf https://open.spotify.com/ gehe und dort dann irgendeinen Link klicke, der 'ne Url in der Form

Delphi-Quellcode:

'https://open.spotify.com/playlist/'

enthält, erhalte ich häufig Sorry, couldn't find that., als HTTP-Code also 404.

Haben die da ein Problem und nicht Du?

Das war auch mein erster Gedanke. Aber wieso 'finden' Firefox und Edge die Seite?

Gruß LP

[Delphi.Narium]

Welche Seite finden die bitte:

Die Tatsache, dass eine Fehlermeldung ausgegeben wird, ist nicht gleichbedeutend mit "Seite wurde gefunden".

HTTP-Code 404 heißt: Das Gesucht gibt es nicht.
HTTP-Code 404 heißt nicht: Es wird keine Ergebnisseite ausgegeben.

Auf der Webkonsole zeigt mir auch der FireFox an, dass er als Ergebnis HTTP-Code 404 bekommt.

Code:

https://open.spotify.com/playlist/621KN721wf1KvuZu8ZUgcw

GET https://open.spotify.com/playlist/621KN721wf1KvuZu8ZUgcw [HTTP/2.0 404 Not Found 171ms]
GET https://open.scdn.co/cdn/build/open/open.3d087318.css [HTTP/1.1 200 OK 0ms]
GET https://open.scdn.co/cdn/images/spotifylogo.a884cca3.svg [HTTP/1.1 200 OK 0ms]
GET https://open.scdn.co/cdn/images/home-icon.ba66757a.svg [HTTP/1.1 200 OK 0ms]
GET https://open.scdn.co/cdn/images/vinyl-top-layer.b56c3ccf.svg [HTTP/1.1 200 OK 0ms]
GET https://open.scdn.co/cdn/images/vinyl-bottom-layer.82d9f6ef.svg [HTTP/1.1 200 OK 0ms]
GET https://open.scdn.co/cdn/fonts/CircularSpUIv3T-Light.afd9ab26.woff2 [HTTP/1.1 200 OK 0ms]
GET https://open.scdn.co/cdn/fonts/CircularSpUIv3T-Bold.8d0a45cc.woff2 [HTTP/1.1 200 OK 0ms]
GET https://open.scdn.co/cdn/fonts/CircularSpUIv3T-Book.3466e0ec.woff2 [HTTP/1.1 200 OK 0ms]
GET https://open.scdn.co/cdn/fonts/CircularSpUICyrOnly-Book.6a858994.woff2 [HTTP/1.1 200 OK 0ms]
GET https://open.scdn.co/cdn/fonts/CircularSpUIAraOnly-Book.aaab109b.woff2 [HTTP/1.1 200 OK 0ms]
GET https://open.scdn.co/cdn/fonts/CircularSpUIHbrOnly-Book.cb36b6ec.woff2 [HTTP/1.1 200 OK 0ms]

Der HTTP-Code ist ein nummerischer Wert, der vom Server geliefert wird, damit der Client entscheiden kann, wie mit der Antwort umzugehen ist.

https://de.wikipedia.org/wiki/HTTP-Statuscode

Man kann auch grob sagen:

Browser finden grundsätzlich nichts.
Sie bitten jemanden, unter Angabe einer Url, etwas für sie zu suchen.
Der Suchende gibt mit Hilfe des HTTP-Statuscode bekannt, ob er was gefunden hat und liefert ggfls. ein entsprechendes Ergebnis (z. B. in Form einer HTML-Seite) aus.
Der Browser reagiert auf den HTTP-Statuscode.
Wird im Fehlerfalle vom Suchenden eine anzeigbare HTML-Seite geliefert, so zeigt der Browser diese an, andernfalls generiert er selbst eine entsprechende Fehlermeldung.

[TiGü]

Mal von all dem abgesehen...warum nimmst du nicht die öffentlich verfügbare WebAPI?
Da kannst du ganz bequem per REST dir JSON-Daten zu allen möglichen holen:

https://developer.spotify.com/documentation/web-api/

Ist auch relativ simpel und gut dokumentiert.

[Maekkelrajter]

Zitat:

Zitat von TiGü (Beitrag 1472521)

Mal von all dem abgesehen...warum nimmst du nicht die öffentlich verfügbare WebAPI?
Da kannst du ganz bequem per REST dir JSON-Daten zu allen möglichen holen:

https://developer.spotify.com/documentation/web-api/

Ist auch relativ simpel und gut dokumentiert.

Als ich mich vor Jahren erstmalig mit der Materie beschäftigt habe, war, wenn ich mich recht erinnere, die Spotify WebAPI nur für Inhaber eines Premium-Accounts verfügbar. Das scheint mittlerweile anders zu sein. Schon seit Tagen beschäftige ich mich mit dieser durchaus attraktiven Alternative. Auch wenn es 'relativ simpel' ist, bedeutet das für mich doch weitgehend Neuland. Schau'n wir mal...
Mein aktuelles Problem hatte ich ja eigentlich schon gelöst bzw. umgangen. Mich interessierte eben, wieso einige Browser eine Seite, die angeblich nicht existiert, dennoch ausgeben können :shock:

Gruß LP

[himitsu]

Einige Browser zeigen bei einem HTTP-ErrorCode eine Fehlerseite an.
Andere Browser zeigen die Seite mit dem StatusCode nur an, wenn es keinen Kontent gibt.

Jetzt könnte man als WebEntwickler gemein sein (oder doof) und trotz ausgabe eines Contents dennoch als Status 404 zurück geben. :angle2:

Es kann aber auch sein, dass die Webseite (HTTP Header/JavaScript/...) eine Erkennung für Browser hat und je nach Browser.Model/Version ein bissl was anderes macht.
Sowas kann sogar direkt im WebServer und nicht erst clientseitig sein, also Anhand der Browser-Kennung im Request-Header.


Außerdem wird der gesamte "Inhalt" der genannten Webseite via JavaScript nachgeladen.
Dein Download verarbeitet kein JavaScript, also bleibt da so oder so nur eine nutzlose HTML-Struktur übrig, selbst wenn du das 404-Problem behebst.

Einzige "richtige" Lösung wäre z.B. eine zugängliche REST-API des Seitenbetreibers.
Außerdem glaube ich kaum, dass der Seitenbetreiber das Runterladen, Parsen und Auslesen der Webseiten erlaubt.

[Delphi.Narium]

Die idhttp hat beim Request auch das Attribut UserAgent. Der Defaultwert dort ist nicht immer unbedingt geeignet. Da gibt es durchaus Server, die eine Kommunikation mit soeinem UserAgent ablehnen.

Gibt dort doch mal den Wert für einen der von Dir genutzten Browser, die die gewünschte Seite anzeigen, an.

Dises Seite zeigt Dir den UserAgent des Browsers an, mit dem Du die Seite aufrufst: https://www.whatismybrowser.com/dete...-my-user-agent

Den Wert kannst Du per Copy&Paste in Deine idHTTP-Komponente übernehmen.

Eventuell machst Du Dir das aber auch konfigurierbar, so dass Du den UserAgent über eine Eingabe setzen kannst, damit bei einer erforderlichen Änderung dieses Wertes, das Programm nicht neu erstellt werden muss.

[Maekkelrajter]

Zitat:

Zitat von Delphi.Narium (Beitrag 1472533)

Die idhttp hat beim Request auch das Attribut UserAgent. Der Defaultwert dort ist nicht immer unbedingt geeignet. Da gibt es durchaus Server, die eine Kommunikation mit soeinem UserAgent ablehnen.

Das ist genau die Lösung, aber dadurch werden auch gnadenlos die Schwächen des Designs meines Programms bloßgelegt: Der Server liefert an den 'modernen' UserAgent andere HTML - Sources, die von meinem Programm nicht mehr korrekt ausgelesen werden können. Ich werde wohl nicht darum herumkommen, mich intensiver mit der Spotify WebAPI zu beschäftigen. Aber das wird eine harte Nuss, alldieweil ich da wohl bei Null anfangen muss. Die API ist zwar wirklich gut dokumentiert, aber Begriffe wie 'REST' und 'JSON' sind für mich (bisher) böhmische Dörfer. Ich habe auch bisher nur ein einziges Delphi - Beispiel mit Einbindung der Spotify WebAPI gefunden: https://github.com/jmarioguedes/CodeRageBrasil3_REST. Das läßt sich zwar kompilieren und läuft, wirft aber andauernd Exceptions, mit denen ich (noch) nichts anfangen kann, und zu allem Überfluss enthält der Sourcecode auch noch Bezeichner und Kommentare auf portugiesisch. Falls jemand noch eine bessere Quelle oder ein gutes Tutorial kennt, her damit!

Gruß LP