Page 1 of 2 1 2 LastLast
Results 1 to 15 of 24

Thread: Delphi Sydney json rest

  1. #1

    Delphi Sydney json rest

    Hoi,

    Vrijdag net iets vreemd opgemerkt, bij het versturen van een json via standaard rest components krijg ik een Error 500 terwijl de json perfect opgebouwd is volgens een json parser en via de test 'swagger' website van de firma waarnaar ik het commando verstuur.

    Vrijdag avond heb ik dan ontdekt dat dezelfde json met dezelfde data perfect verstuurd wordt als ik mijn exe build met Delphi Tokyo.
    Enig idee wat er fout zou kunnen zijn en wat de verschillen zijn tussen Delphi Tokyo en Sydney met rest commands?
    Error: HTTP Status 500 - javax.json.stream.JsonParsingException: Invalid token=EOF at (line no=1, column no=0, offset=-1). Expected tokens are: [CURLYOPEN, SQUAREOPEN, STRING, NUMBER, TRUE, FALSE, NULL]

    Standaard TRestClient, TRestRequest en TRestresponse componenten.

  2. #2
    Counting your refs Paul-Jan's Avatar
    Join Date
    Feb 2002
    Location
    Lage Zwaluwe
    Posts
    2,143
    Geen antwoord, maar ter verdieping: zijn we het er over eens dat die foutmelding niets anders betekent dan "je stuurt een lege string ipv json"?

    Zou je dat kunnen bevestigen in Fiddler of een andere http monitor? Je weet dan in ieder geval al of het probleem is "oei, er wordt niks geschreven", of "hee, er wordt wel wat geschreven maar hij leest het niet, zijn m'n headers wel goed?"

  3. #3
    Een lege string zal het niet zijn denk ik, ik schrijf de json string net voor execute weg naar een logfile, en zoals ik zei lukt de rest call perfect in Delphi Tokyo.
    Idealiter zou ik idd de geparste json string moeten kunnen zien en de call bekijken via een monitor applicatie.

    Maar misschien heeft iemand al hetzelfde probleem gehad, vandaar de vraag.

  4. #4
    Is het niet omdat de string misschien in een ander formaat is? Dus bv dat hij het converteren van UTF8 niet/wel doet en hiermee een andere EOF (CR LF) krijgt? Afhankelijk van waar de data vandaan komt krijg je soms enkel een carriage return en geen newline, en vooral Windows heeft daar soms moeite mee. Zou eens kijken om de string die je ophaalt eerst te converteren naar een ANSI string, en zo eens proberen.

    https://en.wikipedia.org/wiki/Newline

  5. #5
    Denk het niet, zoals ik zei schrijf ik de json string weg naar een tekst logfile net voor de execute van het restrequest component en die json strings zijn identiek.

  6. #6
    zijn er in de laatste versie van Delphi geen aanpassingen gedaan m.b.t. JSON? Er staat mij hiervan iets bij, wellicht heeft het daar mee te maken?

  7. #7
    Als je je stream weg schrijft naar disk, dan staat je pointer toch op het einde?

    Als je die vervolgens probeert te versturen ziet die (denk ik) dus niks behalve de eof. Denk dat je de position van je stream even op 0 moet zetten.

  8. #8
    Geen idee over welke stream je het hebt Benno, er is geen stream...
    Klasse met properties, object wordt gemaakt, properties op object worden ingevuld, dan wordt de class function 'buildjson' opgeroepen welke TJson.ObjectToJsonString uitvoert.
    Met de log functie wordt de json naar een logfile geschreven welke perfect opgebouwd is.

    Code:
         
          PublishRelationRestRequest.Params.ParameterByName('body').Value := Relation.BuildJson;
          Log('JSON PublishRelationCustomer ' + sLineBreak + PublishRelationRestRequest.Params.ParameterByName('body').Value);
    
          Try
             PublishRelationRestRequest.Execute;
    ......... rest of code
    Met Delphi Tokyo verloopt dit prima, op Sydney dus niet.
    Ik heb net deze middag enkele zaken gezien om de bugreports site en vermoed dat dit in 10.4.1 opgelost is, maar ik moet dus nog heel dat proces doorlopen om Delphi up te daten en alweer alle third party components te installeren...dagje werk.
    Zie https://quality.embarcadero.com/logi...se%2FRSP-29769

    after updating to version 10.4 of Delphi the consumption of the REST API does not load complex objects

  9. #9
    Code:
     javax.json.stream.JsonParsingException
    zette mij op het verkeerde been. Maar dat is natuurlijk de response die je van de andere kant kreeg.

    Hoop dat het met je update naar 10.4.1 is opgelost.

  10. #10
    Net upgedated naar 10.4.1...Zelfde probleem.
    Ik snap het echt niet, ik kan met Fiddler zien wat er gestuurd wordt, json is identiek aan de json in Tokyo en bevat geen fouten.
    Gaat prima door een json parser.
    En toch krijg ik Error 500:Expected tokens are: [CURLYOPEN, SQUAREOPEN, STRING, NUMBER, TRUE, FALSE, NULL]</u></p><p><b>description</b> <u>The server encountered an internal error that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>javax.servlet.ServletException: javax.json.stream.JsonParsingException: Invalid token=EOF at (line no=1, column no=0, offset=-1). Expected tokens are: [CURLYOPEN, SQUAREOPEN, STRING, NUMBER, TRUE, FALSE, NULL]

    Ik heb nu de ontvangende partij gevraagd als zij kunnen zien wat er fout is aan de data die bij hen aankomt en die de error 500 genereerd.

  11. #11
    Je schreef eerder dat je logt.

    Wat zie je in de oude werkende en de nieuwe niet werkende versie als je de logfile opent met bv Notepad++ -> Beeld -> Niet afdrukbare tekens -> Alle karakters weergeven?

  12. #12
    Goed idee, ik heb de logs op beide omgevingen met notepad++ geopend maar in beide gevallen staan er geen 'onzichtbare' karakters in de json strings.

  13. #13
    als je fiddler hebt, kun je dan eens in de log kijken wat daarin terecht komt. Je kunt die als een soort proxy gebruiken, daarna kun je gewoon op de json inzoomen.

  14. #14
    Ja ik heb het met fiddler bekeken, json die daar in staat is foutloos.
    Maar ik denk ineens aan iets...de Delphi Sydney staat op een remote azure server...misschien is het gewoon een probleem op die server omdat er iets geblokkeerd wordt of zo, even testen met die exe op een andere omgeving.
    Maar dat verklaart dan niet waarom andere json statements wel prima doorgaan.

  15. #15
    Het zou kunnen dat die azure ip range geblocked staat om uberhaupt requests te mogen doen?

    Of dat ze inderdaad op die server outbound rules hebben staan in de firewall. Maar dan zou vanaf die server niets mogen werken.

    Is het mogelijk een client-certificaat probleem of zo? Dat certificaat op jouw machine met 10.3 wel is geinstalleerd en op de azure bak (nog) niet?

Page 1 of 2 1 2 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •