python post-request probleme

[Chandler B. (chandler)]

Hallo,
ich möchte gerne mit python und requests dateien von 
https://garmin-connect-weight-api.onrender.com/ runterladen.
Damit bekomme ich dann .fit-Dateien, die ich auf Garmin hochladen kann.
Da kann man folgendes importieren:
Garmin-Aktivitätsdateien (TCX-, FIT- oder GPX-Format)
Fitbit®-Daten zu Gesundheit oder Aktivitäten (XLS-, XLSX- oder 
CSV-Format).

Ich kann die Daten von meiner Waage/App (Waage: Fitleap; App: Fitdays) 
als .xlsx exportieren 
(Beitrag "csv parsen kryptische Symbole"), aber dies ist 
dennoch ein anderes Format.

mein Problem ist aber, dass das mit dem post-request bei mir nicht so 
ganz funktioniert

import requests

if __name__ == '__main__':
    url = 'https://garmin-connect-weight-api.onrender.com'
    headers = {"Content-Type": "application/json", "Content-Length":"73", "path":"weight", "Accept-Language":"de", "Accept":"*/*", "Origin":"https://garmin-connect-weight-api.onrender.com"}
    data={"weight":80.1, "percentFat":20,}
    
    response=requests.post(url, headers=headers, json=data)
    print(response.status_code)

mein Status-Code ist 405.

Wenn ich "/weight" an meiner url direkt mit anhäge, bekomme ich einen 
status_code=500.

Hat jemand einen tip woran das liegt?

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Chandler B. schrieb:
> mein Status-Code ist 405.

Method not allowed. Die statt dessen zulässigen Request-Methoden stehen 
im Allow-Header der 405-Antwort.

[Ein T. (ein_typ)]

Chandler B. schrieb:
> ich möchte gerne mit python und requests dateien von
> https://garmin-connect-weight-api.onrender.com/ runterladen.
> Damit bekomme ich dann .fit-Dateien, die ich auf Garmin hochladen kann.
> [...]
> mein Problem ist aber, dass das mit dem post-request bei mir nicht so
> ganz funktioniert
>

>     headers = {"Content-Type": "application/json", 
> "Content-Length":"73", "path":"weight", "Accept-Language":"de", 
> "Accept":"*/*", 
> "Origin":"https://garmin-connect-weight-api.onrender.com"}
>     data={"weight":80.1, "percentFat":20,}
>

> [...]
> Hat jemand einen tip woran das liegt?

Ja, an zwei Dingen: erstens POSTest DU auf den flashcen URL, deswegen 
kommt dort korrekterweise ein 405 ("Method not allowed"). Wenn ich das 
ECMAScript unten auf der Seite richtig lese, ist "/weight" der korrekte 
Endpunkt.

Auf "/weight" kommt jedoch das zweite Ding zum Tragen, Du POSTest 
nämlich gar kein JSON, wenngleich Dein Header das behauptet. In Wahrheit 
sendest Du Daten im MIME-Typ "application/x-www-form-urlencoded" -- das 
macht requests nämlich so, wenn "data" ein Dictionary übergeben wird. 
Der Server sieht also den Body 'weight=80.1&percentFat=20' anstelle des 
ausweislich des genannten ECMAScript gewünschten JSON-Formats 
'{"weight":80.1,"percentFat":20}'.

Dein "Content-type"-Header behauptet also einen anderen Content-type als 
Du  sendest. Der Server wird dann versuchen, Deinen Body in 
"application/x-www-form-urlencoded" mit einem JSON-Parser zu dekodieren. 
Das schlägt natürlich fehl und deswegen bekommst Du einen HTTP/500 
"Internal Server Error" zurück. So weit, so korrekt.

Wenn Du "application/json" senden willst, wie es dieser Service 
anscheinend erwartet, dann mußt Du Deine Daten entsprechend formatieren, 
zum Beispiel mit der Funktion "dumps" aus den Standardmodul "json" -- 
das macht "requests" nicht automatisch für Dich, nur weil Du den 
Content-type gesetzt hast.

Ein wohlerzogener Server könnte möglicherweise auch Daten in 
"application/x-www-form-urlencoded" verarbeiten, wenn der Header korrekt 
gesetzt wäre. Aber ich würde mich an Deiner Stelle eher nicht darauf 
verlassen. :-)

[Franko S. (frank_s866)]

Dein Contentlength stimmt nicht, wenn ich den weglasse geht es:

curl \
-D headers_received.txt \
-H 'Content-Type: application/json' \
-H 'path: weight' \
-H 'Accept-Language: de' \
-H 'Accept: */*' \
-H 'Origin: https://garmin-connect-weight-api.onrender.com' \
-H 'Accept-Language: de,en-US;q=0.7,en;q=0.3' \
-H 'Accept-Encoding: gzip, deflate, br, zstd' \
-H 'Referer: https://garmin-connect-weight-api.onrender.com/' \
-H 'Alt-Used: garmin-connect-weight-api.onrender.com' \
-H 'Connection: keep-alive' \
-H 'Sec-Fetch-Dest: empty' \
-H 'Sec-Fetch-Mode: cors' \
-H 'Sec-Fetch-Site: same-origin' \
-H 'Priority: u=0' \
-H 'TE: trailers' \
--data '{"weight":80.1, "percentFat":20}' \
-X POST \
--output fettsack.fit \
https://garmin-connect-weight-api.onrender.com/weight

[Ein T. (ein_typ)]

Franko S. schrieb:
> Dein Contentlength stimmt nicht,

Das ist aber nicht der Punkt.

>

> --data '{"weight":80.1, "percentFat":20}' 
>

Der Punkt ist hier, daß Du einen korrekten JSON-String schickst. Darum 
klappt es bei Dir. Der TO schickt aber keinen JSON-String, und das 
schlägt fehl.

[Franko S. (frank_s866)]

Ein T. schrieb:
> Franko S. schrieb:
>> Dein Contentlength stimmt nicht,
>
> Das ist aber nicht der Punkt.
>
>>> --data '{"weight":80.1, "percentFat":20}'
>>
>
> Der Punkt ist hier, daß Du einen korrekten JSON-String schickst. Darum
> klappt es bei Dir.
Und seine fasche Content-length weglasse. Setzt man diese funktioniert 
es nämlich nicht mehr obwohl der Rest korrekt ist also liegt es auch an 
seinem falschen Content-Length-Angabe.

> Der TO schickt aber keinen JSON-String, und das schlägt fehl.
ja, u.a. Was das Pythondignens reponse da noch vorher drann 
rumflickwerkt weiss auch keiner.
Deshalb nimmt man erst mal curl und schaut ob es formal richtig ist, 
wenn es dann immer noch nicht geht, liegt es an der der request-lib von 
Python oder was auch immer man da verwendet.
Content-Length selber setzen ist eh meistens überflüssig wenn man ne lib 
nutzt, die erzeugt das automatisch richtig, vor allem wenn man das noch 
encoded, packt,... ausser man fummelt da ohne lib herum, von einem Mc 
heraus wo man http noch selber zusammenklöppelt weil der MC zu 
schwach/wenig Speicher hat.

[Ein T. (ein_typ)]

Franko S. schrieb:
> Ein T. schrieb:
>> Franko S. schrieb:
>>> Dein Contentlength stimmt nicht,
>>
>> Der Punkt ist hier, daß Du einen korrekten JSON-String schickst. Darum
>> klappt es bei Dir.
>>
> Und seine fasche Content-length weglasse. Setzt man diese funktioniert
> es nämlich nicht mehr obwohl der Rest korrekt ist also liegt es auch an
> seinem falschen Content-Length-Angabe.

Ja, äh... nein. Es ist nicht seine falsche Content-Length-Angabe, 
sondern es ist leider Deine falsche Content-Length-Angabe, wie wir 
gleich sehen.

> Deshalb nimmt man erst mal curl und schaut ob es formal richtig ist,

... und baut dabei einen neuen Fehler ein, der mit dem ursprünglichen 
leider nichts zu tun hat. War gut gemeint von Dir, aber... :-)

> wenn es dann immer noch nicht geht, liegt es an der der request-lib von
> Python oder was auch immer man da verwendet.

Ach, weißt Du, das "requests"-Paket in Python ist weit verbreitet und 
gut getestet, da würde ich mal vermuten, daß es seine Sache richtig 
macht. Und siehe da: das tut es dann auch.

Das "requests"-Modul setzt die Content-Length nämlich vollkommen 
korrekt, und zwar unabhängig davon, ob und wie sie im Header angegeben 
wurde. Der Request

requests.post(
    "http://localhost:2000", 
    data=json.dumps({'foo': 'bar', 'num': 2}), 
    headers={"Content-Length": "234"}
)

schickt die korrekte Content-Length von 24:

POST /asdf
User-Agent: python-requests/2.31.0
Accept-Encoding: gzip, deflate, br
Accept: */*
Connection: keep-alive
Host: localhost:2000
Content-Length: 21

{"foo":"bar","num":2}

Beispiel-Server und -Client habe ich angehängt, wenn es jemand selbst 
ausprobieren möchte. Viel Spaß! :-)

[Franko S. (frank_s866)]

Ein T. schrieb:

Ok wenn die request-lib das automatisch immer korrekt setzt dann hast du 
nat. recht.