Problém s HTTP headerem

jenya

Zdravím,
zákazník, programátor řeší problém, že tento kód: curl -X POST --location "https://api.engine.tech/leads/rateTables" -H "Authorization: Bearer tests-token" -d '{}'
mu vypíše hlášku "Illegal character 'ý' in header value"
Problém je, že se tak děje při použití naší sítě. Pokud se připojí na hotspot přes mobil, tam to funguje.
Nesetkal jste se s tím někdo, resp. jak to řešit?

zdeneksvarc

jenya "Illegal character 'ý' in header value"

Znamená, že v Authorization: Bearer tests-token byl někde v tom řetězci schovaném za test-oken znak ý. Což je samozřejmě špatně, protože hodnoty kódované v Base64 takovej znak nepřipouští. Pokud nic po cestě nemanipuluje HTTPS provoz, pak si nedokážu představit chybu jinde, než na straně API serveru nebo API požadavku.

Nevím, co je engine.tech server zač. Už jenom to, že na POST i GET metodu při neúplném dotazu odpovídá stejným nesmyslem, asi nesvědčí o velké odladěnosti.

curl -X POST https://api.engine.tech
Illegal character '\u0010' in header value%   

curl https://api.engine.tech
Illegal character '\u0010' in header value%

skrivy

Doporučuji kontaktovat podporu dané služby. Ještě bych k tomu přidal --verbose, aby bylo vidět vše.

coitus

Bohuzial su aj programatory co nevedia na co je http header a ze s pripojenim k internetu nema nic spolocne (teda pokial provider nepouziva proxy co asi nebude tento pripad). Naviac je to httpS a tam uz akekolvek zasahovanie do prenasanych dat zo strany ISP nie je mozne.

pixall

zdeneksvarc Z popisu IMHO nevyplyva, v ktorej hlavicke sa nachadza problemovy znak. Hlavicka Autorization, ktora je specifikovana v prikazovom riadku, sa pridava ako dalsia k ostatnym hlavickam, ktore tam natlaci CURL.
V prvom rade by to chcelo pustit ten request v CURL s co najvyssou verbositou, tak aby bolo vidiet, co presne sa posiela druhej strane. Mozno to bude nejaka blbina v zmysle, ze CURL pridava do hlaviciek nieco, co zavisi na pouzitom pripojeni, a v com je zadany nepovoleny znak.

cerva

Z naší sítě dostávám stejnou chybu - Illegal character 'ý' in header value

Přes curl -vX POST https://api.engine.tech trasovány headery a posílám jen:

POST / HTTP/2 Host: api.engine.tech user-agent: curl/7.88.1 accept: */*

Chyba někde na straně poskytovatele API - třeba na reverzní proxy, která do headeru requestu přidává, co nemá, nebo v samotném API.

jenya

cerva Ano, zkoušel jsem to na další síti lokálního poskytovatele a výsledkek stejný - Illegal character 'ý' in header value.
Ale teď si na telefonu vypni wifi a zkus to samé, přes mobilní data a odpověď je:
{
"message": "Bad request.",
"details": "Cannot parse parameter uuid as UUID: Invalid UUID string: rateTables"
}

coitus

Typujem to na parameter "host" ktory posiela meno pocitaca a ked tam ma niekto uvedene meno z diakritikou napr. Dvorský tak je problem na svete...

cerva

jenya Jasně, z některých míst to jede, třeba i odtud: https://reqbin.com/curl

Podstata problému je, že v HTTPS requestu od klienta (spuštěný curl nebo pak i wget u mě na PC) žádný header s "ý" jednoznačně není. Na naší síti k modifikaci HTTPS provozu nedochází, na api.engine.tech:443 tedy spolehlivě přiletí request v podobě, v jaké ho curl odeslal. Následně to server api.engine.tech, který se překládá na IP adresy od Cloudflare, takže je to asi proxy/load balancer, posílá někam na CloudFront od Amazonu WS - zde se headery už určitě nějak modifikují. V Amazonu pak pojede samotná služba s app logikou. V HTTP response je header x-cache: Error from cloudfront a x-amzn-remapped-content-length: 38, takže chybu vrací až ta app logika v Amazonu na základě přijatých headerů.

Chyba v nastavení cloudflare proxy nebo v implementaci API. Cloudflare třeba umí vkládat geolokaci klienta už do headeru - nevyskytne se tam kraj s ý na konci :-) (https://developers.cloudflare.com/rules/transform/managed-transforms/reference/#add-visitor-location-headers)?

miract

Pokud to pomůže, tak teď jsem to zkoušel z hraničních linuxů na dvou nezávislých konektivitách a tam to projde. Když to samé pustím z linuxu na vnitřní síti, tak to hlásí to s tím "ý".

Řekl bych, že se mu nelíbí něco na NATu. Proto to možná u mobilkáře projde.

cerva

miract Na páteři je geolokace do Prahy nebo do kraje s ý na konci? Veřejka z LTE se mi trefuje vždy do Prahy.

Když se nad tím zamyslím, bude to téměř jistě tento problém. Cloudflare přidá header cf-region: Pardubický kraj a pošle to do Amazonu, kde to app vyhodí, že je v headeru ý.

zajdee

cerva co me prekvapuje: mam adresu z "Ústecký kraj" a to API si porad stezuje jen na "ý" 😅

miract

To by odpovídalo, neboť oba spojováky jsou Praha a veřejky s NATem "...cký"

jcltm

To by člověk neřekl, jak vážný problém ještě dneska představuje diakritika...

cerva

zajdee potrebujeme testera z Vysociny 😄

soban

zajdee
A nemůže být spíš problém s tou mezerou po "ý" ?
A jako chyba se pak zobrazí "ý" protože mezeru nevidíš?

pixall

zajdee co me prekvapuje: mam adresu z "Ústecký kraj" a to API si porad stezuje jen na "ý" 😅

nie je znak ako znak. niektore znaky maju ekvivalenty v roznych kodovych tabulkach, ine nie. podla toho ako je to nakodovane, niektore znaky mozu preliezt v pohode. pamatam podobne problemy pri zapisoch do SQL databazy alebo aj v niektorych telekomunikacnych zariadeniach, ze niektore znaky z diakritikou fungovali v pohode a na niektorych sa to hodilo o zem.