C# a POST požadavek nebo náhrada Webclineta

[Martin Dráb]

A doufám, že až příště začnete na něčem pracovat, důkladně se seznámíte s protokolem pro USB, abyste věděl, jak s počítačem komunikuje myš a klávesnice, se všemi protokoly síťové vrstvy a s veškerou dostupnou dokumentací pro úplně všechno co ve vašem projektu je.

Pokud budu programovat zařízení, co komunikuje přes USB na dostatečně nízké úrovni, tak mi nic jiného než jisté seznámení s touto sběrnicí nezbude.

Podobně jako když třeba používám pro síťovou komunikaci sockety, měl bych vědět něco o vrstvách, které jsou pod nimi (zdaleka ne všechno), protože pak různé exotičtější chování není takovým překvapením a vlastně dává smysl.

Vyhnete se tak problému, kdy budete řešit podružnou věc, kterou zkusmo otestujete příkazem CURL a budete si myslet, že stačí poslat stejný požadavek 

Tak, v POST požadavku vygenerovaném metodou UploadFile je vidět nějaká struktura, která má zřejmě nějaký svůj vnitřní smysl (tzn. nedá se předpokládat, že by si ji vývojáři zodpovědní za UploadFile vycucali z prstu). RFC jsou sice celkem dlouhá, ale obvykle stačí jen proletět příslušné pasáže. Google samozřejmě také pomůže, ale je třeba být opatrný.

V minulém příspěvku jsem si dovolil drobné popíchnutí, neb je poměrně obtížné čistě neutrálně reagovat na vaše, zejména ty první, příspěvky.

[Reklama]

[PanVP]

V minulém příspěvku jsem si dovolil drobné popíchnutí, neb je poměrně obtížné čistě neutrálně reagovat na vaše, zejména ty první, příspěvky.

Uznávám, byl jsem z toho vzteky bez sebe a RFC jsem si přečíst mohl, nicméně poctivému Googlování jsem se věnoval dva dny, ale po bitvě je každý generál. 

Obecně jsem očekával, že když PUT má nějakou hlavičku, že pro POST (což by měl být v podstatě podobný požadavek) to bude stejné. Navíc jsem si svojí, uznávám chybnou, tezi potvrdil CURLem i Pythonem.

Jinými slovy, řadou svých pokusů jsem chybně vyloučil možnost "že by to M$" mohl mít správně.
Včetně toho pokusu, kdy jsem si uložil požadavek do souboru a poslal ho bez "boundary" serveru, který si s tím poradil.

Doplním, že ten ukázkový příklad z dokumentace k API také nefunguje, Chrome tam také rve boundary=-----
Pokud se k tomu dostanu, zkusím i nějakou historickou verzi IE, jestli se něco změní.

[Martin Dráb]

Obecně jsem očekával, že když PUT má nějakou hlavičku, že pro POST (což by měl být v podstatě podobný požadavek) to bude stejné. Navíc jsem si svojí, uznávám chybnou, tezi potvrdil CURLem i Pythonem.

Myslím, že není nikde definováno, že každý POST požadavek má používat multipart/boundary. K tomu se klient uchyluje, pokud chce v rámci jednoho požadavku odeslat více bloků (různých) dat. Při odesílání souboru se do požadavku přidává jak jejich obsah, tak i nějaké doplňující informace (např. jméno na disku klienta).

Nevím, zda PUT nedovoluje použít také podobný přístup (multipart/boundary), ta RFC jsem četl již celkem dávno. Ono je někdy dost rozdíl v tom, co RFC dovoluje/doporučuje/vynucuje a co se v praxi obvykle používá/implementuje.

[Filip Jirsák]

Doplním, že ten ukázkový příklad z dokumentace k API také nefunguje, Chrome tam také rve boundary=-----
Pokud se k tomu dostanu, zkusím i nějakou historickou verzi IE, jestli se něco změní.

Nezmění. Z prohlížeče odesíláte formulář, v jehož rámci se uploaduje soubor. To je něco úplně jiného, než odeslání XML dat na server.

V těle HTTP požadavku se mohou posílat libovolná data (v libovolném formátu). Aby server věděl, o jaký formát dat jde, posílá se hlavička Content-Type. Váš REST server očekává jako typ dat na vstupu XML. Prohlížeče při odesílání HTML formulářů používají typ dat pro HTML formulář (existují dva, jeden pro formuláře bez uploadu souboru, druhý pro formulář se uploadem souboru). Váš server s tím formulářovým typem neumí pracovat (což je celkem logické).

Vaše pokusy posílat formulář tam, kde je očekáváno XML, jsou stejné, jako kdybyste se pokoušel otevřít video soubor v textovém procesoru. Když se vám nepovedlo otevřít video v Libre Office, je zbytečné zkoušet to ještě ve starší verzi a v MS Wordu. Prostě textové procesory video otvírat neumí. A stejně tak váš REST server umí zpracovat „soubor“ XML ale ne soubor s HTML formulářem.

[Filip Jirsák]

Myslím, že není nikde definováno, že každý POST požadavek má používat multipart/boundary.

Nikde to definováno není, v POSTu samozřejmě může být jakýkoli obsah, stejně jako u všech ostatních metod.

K tomu se klient uchyluje, pokud chce v rámci jednoho požadavku odeslat více bloků (různých) dat.

Ve skutečnosti to používají jenom prohlížeče pro upload souborů z webového formuláře, a pak aplikace, které tenhle upload chtějí simulovat. Žádné jiné použití multipart/form-data jsem neviděl – pokud nějaké API potřebuje získat více částí, dělá se to samostatnými voláními. Ostatně povšimněte si, že ten typ se jmenuje form-data, má to přímo v názvu, že je určen pro odesílání formulářových dat.

Nevím, zda PUT nedovoluje použít také podobný přístup (multipart/boundary)

Povoluje, resp. HTTP standard vůbec neřeší, jaké mime-typy se kde mohou poslat. Ten typ samozřejmě můžete použít, ale musíte vědět, že server ho umí zpracovat. A bude to vaše unikátní řešení – ten typ se normálně používá jen v prohlížečích pro odeslání formuláře se souborem, a pro to se vždy používá metoda POST. Prohlížeče samy o sobě metodu PUT na webu nikdy nepoužívají. (Něco jiného je samozřejmě AJAXový kód v JavaScriptu, tam si zase můžete HTTP požadavky sestavovat, jak chcete. A něco jiného je případná podpora WebDAVu nebo jiných protokolů v prohlížeči.)

[Reklama]