Delphi 11.3 schon da?

[Bbommel]

Zitat von Uwe Raabe:

Zitat von Bbommel:

https://quality.embarcadero.com/browse/RSP-40726

Ja, so was in der Art hatte ich auch schon: https://quality.embarcadero.com/browse/RSP-40549

Allerdings konnte ich mir wie im Report beschrieben mit einem Workaround helfen. Keine Ahnung ob der bei dir auch funktioniert.

Hm, du hast in deinem Report angegeben, dass er sich auf 11.2 bezieht. Hast du dich da verklickt oder klappt das tatsächlich unter 11.2 nicht? Das wundert mich, denn unter 11.2 ist der Code zwar auch Schrott, aber er ist in einer Form Schrott, dass trotzdem eigentlich alle APIs, die ein JSON zurückgeben, funktionieren müssten, auch deine. Das, was ich in meinem Bugreport geschrieben habe, müsste auch bei dir zutreffen (klingt jetzt nach "mein Report ist besser als deiner!", ist aber nicht so gemeint ): Bei deinem Content-Type von "application/json; api-version=7.1-preview.3" liefern sowohl 11.2 als auch 11.3 als LMimeKind ein "Unknwon". Danach kommt in 11.2 ja folgende Code:

Delphi-Quellcode:

          if (FClient.FallbackCharsetEncoding <> '') and
             not SameText(REST_NO_FALLBACK_CHARSET, FClient.FallbackCharsetEncoding) then
          begin
            // Skip some obvious binary types
            if LMimeKind <> TMimeTypes.TKind.Binary then
            begin
              LEncoding := TEncoding.GetEncoding(FClient.FallbackCharsetEncoding);
              LContentIsString := True;
            end;
          end
          else
          begin
            // Even if no fallback, handle some obvious string types
            if LMimeKind = TMimeTypes.TKind.Text then
              LContentIsString := True;
          end;

Das heißt, wenn du nicht vorher in deinem Code das "FallbackCharset" geleert oder auf "raw" gesetzt hast, wirst du im ersten Teil der if-Abfrage landen und da das MimeKind nicht "Binary" ist, sollte dein Content gesetzt werden. So wie das da steht, ist das auch alles quatsch, weil, wenn ich nichts übersehe, ein tatsächlich gesetztes Encoding komplett ignoriert wird. Aber da die meisten APIs heutzutage wohl mit UTF8 arbeiten und ein JSON liefern, funktioniert es am Ende des Tages halt trotzdem.

In 11.3 aber nicht mehr, weil sie die Logik komplett umgekehrt haben. Nur dann, wenn der MimeType wirklich als Text erkannt wird, wird er auch wie bisher ausgewertet. Das finde ich ziemlich dämlich, denn jetzt verlassen sie sich auf ihre fest vorgegebene, endliche Aufzählung im Dictionary und dazu kommt eben das Problem mit dem aus mehreren Teilen bestehenden Content-Type, was sich jetzt eben bemerkbar macht. Hier ist der Punkt, der mich tatsächlich fassungslos macht: da wird an einer der zentralsten Stellen des ganzen REST-Frameworks eine Funktion massiv geändert und niemand testet das vernünftig? Das ist ja jetzt nicht irgendwas absurdes, sondern OData (wo das mit dem Content-Type regelmäßig vorkommt) ist weit verbreitet.

Merkwürdig finde ich aber tatsächlich immer noch, dass das bei dir auch unter 11.2 auftritt. Müsstest du vielleicht nochmal näher nachschauen.

[Uwe Raabe]

Zitat von Bbommel:

Merkwürdig finde ich aber tatsächlich immer noch, dass das bei dir auch unter 11.2 auftritt. Müsstest du vielleicht nochmal näher nachschauen.

Ist aber so. War auch schon vorher so, ist aber erst aufgefallen nachdem Azure DevOps nun die Version im ContentType mitliefert.

[Bbommel]

Zitat von Uwe Raabe:

Zitat von Bbommel:

Merkwürdig finde ich aber tatsächlich immer noch, dass das bei dir auch unter 11.2 auftritt. Müsstest du vielleicht nochmal näher nachschauen.

Ist aber so. War auch schon vorher so, ist aber erst aufgefallen nachdem Azure DevOps nun die Version im ContentType mitliefert.

Aber dann schau doch mal nach, warum der bei dir nicht im erwähnten Teil landet unter 11.2. Dann könnte man das in den jeweiligen Bugreports noch besser hervorheben und so einer wirklich guten Lösung näherkommen (wobei, ja, das wichtigste wäre die richtige Auswertung des mehrteiligen Content-Types). Dennoch fände ich das spannend, warum sich das bei dir anders verhält unter 11.2 als bei mir. Aber wir kommen damit langsam zugegebenermaßen etwas vom Thema des Threads ab.

[Uwe Raabe]

Ist auch mittlerweile für mich schwierig das nachzuverfolgen, da ich alle 11.2 schon auf 11.3 upgedated habe. Lediglich theoretisch anhand der RTL-Sourcen kann ich das versuchen zu analysieren.

Das Problem war für mich ganz sicher in 11.2 schon vorhanden, aber der Report sagt ja lediglich, dass application/json nicht erkannt wird, worauf das JSONValue Property nicht gefüllt wurde. Bei dir ist das zwar auch so, aber mit 11.3 ist zusätzlich der Content leer.

Den 11.3 Code habe ich damit noch gar nicht probiert, aber da ich den Workaround noch eingebaut habe gehe ich davon aus, dass TMimeTypes.Default.GetTypeInfo immer noch den korrekten Mimetype liefert und die in 11.3 eingebaute Fallback-Lösung (vermutlich ein Fix für RSP-39994) nicht relevant ist.

Ich kenne jetzt nicht die Bandbreite der in deinem Fall ankommenden ContentType. Wenn das eine überschaubare Menge ist, könntest du die ja auch vorab registrieren. Bei mir habe ich das in einen class constructor für die API-Klasse gemacht:

Delphi-Quellcode:

class constructor TDevOpsApi.ClassCreate;
begin
  for var I := 2 to 4 do
    TMimeTypes.Default.AddType('json', Format('application/json; api-version=7.1-preview.%d', [I]), TMimeTypes.TKind.Text, True);
end;

Alternativ kannst du auch über RawBytes an die Daten kommen.

[Bbommel]

Zitat von Uwe Raabe:

Das Problem war für mich ganz sicher in 11.2 schon vorhanden, aber der Report sagt ja lediglich, dass application/json nicht erkannt wird, worauf das JSONValue Property nicht gefüllt wurde. Bei dir ist das zwar auch so, aber mit 11.3 ist zusätzlich der Content leer.

Unter 11.2 wird bei mir auch bei dem erweiterten Content-Type sowohl der Content gefüllt als auch das JSONValue gesetzt (weil er dafür ja auch einfach nur ein ParseJsonValue mit dem Content aufruft, wenn man zum ersten Mal auf die Property JSONValue zugreift - was in dem Moment im Content-Type stand, ist nicht mehr relevant). Erst in 11.3 ist es kaputt. Aber gut, wenn du kein 11.2 mehr hast, dann werden wir es wahrscheinlich nie erfahren, warum es bei anders lief als bei mir. Das ist wahrscheinlich keine öffentliche API, die ich auch mal testen könnte, oder? Jetzt ist einfach meine Neugierde geweckt.

Zitat:

Ich kenne jetzt nicht die Bandbreite der in deinem Fall ankommenden ContentType. Wenn das eine überschaubare Menge ist, könntest du die ja auch vorab registrieren. Bei mir habe ich das in einen class constructor für die API-Klasse gemacht:
[...]

Danke - das ist auf jeden Fall auch ein wichtiger Hinweis, wenn man mal eine API hat, die irgendeinen absurden Content-Type in der Antwort liefert (alles schon gesehen...). In dem konkreten Fall bleiben wir wahrscheinlich erstmal bei der 11.2, die 11.3 ist einfach zu schlecht für unsere Zwecke.

[Uwe Raabe]

Zitat von Bbommel:

Das ist wahrscheinlich keine öffentliche API, die ich auch mal testen könnte, oder? Jetzt ist einfach meine Neugierde geweckt.

Zumindest kann man das kostenfrei bekommen. Auf dieser Seite oben rechts auf Free Account klicken:
Azure DevOps Services REST API Reference

[lxo]

Ist euch aufgefallen, dass das Icon im MessageDlg für mtConfirmation vom blauen Fragezeichen auf das Warnungssymbol geändert wurde?
Weiß jemand von euch mit welcher Begründung sowas gemacht wurde?

Delphi-Quellcode:

 
unit Vcl.Dialogs
  
 
  // Delphi 11.2
  function GetMsgIconResourceName: String;
  begin
    Result := '';
    case DlgType of
      mtWarning:
        Result := 'MSG_WARNING';
      mtError:
        Result := 'MSG_ERROR';
      mtInformation,
      mtConfirmation:
        Result := 'MSG_INFO';
    end;
  end;


  // Delphi 11.3
  function GetMsgIconResourceName: String;
  begin
    Result := '';
    case DlgType of
      mtWarning,
      mtConfirmation:
        Result := 'MSG_WARNING';
      mtError:
        Result := 'MSG_ERROR';
      mtInformation:
        Result := 'MSG_INFO';
    end;
  end;