Individualizuotos HTTP antraštės: pavadinimų konvencijos

Keli mūsų naudotojai paprašė įtraukti į savo paskyrą duomenis apie jūsų išsiųstų užklausų HTTP antraštes arba netgi atsakymus, gautus iš mūsų API. Koks yra bendras sutarimas pridėti savo „HTTP“ antraštes pagal pavadinimą , formatą ir tt

Taip pat nedvejodami skelbkite bet kokį protingą šių duomenų naudojimą, kurį jūs suklupsite internete; Mes stengiamės tai pasiekti, naudodami tai, kas geriausia kaip tikslas :)

883
25 авг. nustatė Julien Genestoux 25 rug . 2010-08-25 00:59 '10 - 0:59 2010-08-25 00:59
@ 6 atsakymai

2012 m. Birželio mėn. Pasenusi rekomendacija naudoti priešdėlį „X-“ tapo oficialia kaip RFC 6648 . Toliau pateikiamos atitinkamos nuorodos:

3. Rekomendacijos naujų parametrų kūrėjams

...

  1. NEGALIMA pridėti savo parametrų pavadinimų naudodami „X-“ ar panašius konstrukcijas.

4. Rekomendacijos protokolo kūrėjams

...

  1. NEGALIMA uždrausti parametrų, kurių priešdėlis „X-“ arba panašios konstrukcijos nėra registruojamos.

  2. NEGALIMA nurodyti, kad parametras su prefiksu „X-“ ar panašiomis konstrukcijomis turėtų būti suprantamas kaip nestandartinis.

  3. NEGALIMA nurodyti, kad parametras be prefikso „X-“ ar panašių konstrukcijų turėtų būti suprantamas kaip standartizuotas.

Atkreipkite dėmesį, kad „NEGALIMA“ („nepripažįstama“) nesutampa su „NEGALIMA“ („draudžiama“), taip pat žr. RFC 2119 skirtingą šių raktinių žodžių specifikaciją. Kitaip tariant, galite toliau naudoti prefiksų antraštes „X-“, tačiau tai nerekomenduojama, todėl negalite jų dokumentuoti taip, lyg jie būtų viešai prieinami.


2011 m. Birželio mėn. Pirmasis „ x-gzip“ ir „ gzip lygiavertis. Taigi, rekomenduojama paprasčiausiai juos vadinti protingai be „X-“.


Rekomendacija buvo pradėti savo vardą „X-“. Pavyzdžiui. X-Forwarded-For , X-Requested-With . Tai taip pat minima RFC 2047 5 skyriuje.

969
25 авг. atsakymą pateikė BalusC 25 rug . 2010-08-25 01:02 '10 ne 1:02 2010-08-25 01:02

Klausimas perskaito. Faktinis klausimas nėra panašus į CSS savybių tiekėjo priešdėlį, kur patartina tikrinti ateitį ir pagalvoti apie pardavėjo paramą ir oficialius standartus. Tikrasis klausimas yra labiau panašus į URL parametrų pavadinimų pasirinkimą. Niekas neturėtų rūpintis, kas jie yra. Bet vardų sutapimas su įprastu - tai visiškai teisingas ir bendras, ir teisingas dalykas.

Loginis pagrindas:
Mes kalbame apie kūrėjų susitarimus, susijusius su naudotojų taikomomis antraštėmis - „su jų sąskaita susijusiais duomenimis“, kurie neturi nieko bendra su tiekėjais, standartų įstaigomis ar protokolais, kuriuos turi įgyvendinti trečiosios šalys, išskyrus kūrėją, jums reikia tiesiog vengti antraščių, kurių paskirtis gali būti kitokia nei serverių, įgaliotinių ar klientų naudojimui. Dėl šios priežasties „X-Gzip / Gzip“ ir „X-Forwarded For Foreded For For“ pavyzdžiai yra prieštaringi. Dėl to kyla klausimas dėl konvencijų privačios API kontekste, panašus į URL parametrų pavadinimo konvencijas. Tai yra pirmenybė ir atstumas tarp pavadinimų; susirūpinimas „X-ClientDataFoo“, kurį palaiko bet koks tarpinis serveris arba paslaugų teikėjas be „X“, yra akivaizdžiai nereikšmingas.

Priedas „X-“ nėra ypatingas ar stebuklingas, bet padeda suprasti, kad tai yra pasirinktinė antraštė. Iš tiesų, RFC-6648 ir kt. Padėkite užkirsti kelią „X-“ prefikso naudojimui, nes - kadangi HTTP klientų ir serverių teikėjai atsisako priešdėlį - jūsų paraiškas, privačias API, asmens duomenis, perdavimo mechanizmas yra dar geriau izoliuotas nuo susidūrimai tarp vardų ir nedidelis skaičius oficialių rezervuotų antraštių. Tačiau mano asmeninės nuostatos ir rekomendacijos yra žingsnis toliau ir, pavyzdžiui, „X-ACME-ClientDataFoo“ (jei jūsų įmonė yra „ACME“ valdiklis).

border=0

IMHO IETF specifikacija nėra pakankamai konkreti, kad būtų galima atsakyti į OP klausimą, nes ji negali atskirti visiškai skirtingų naudojimo atvejų: (A) paslaugų teikėjai, diegiantys naujas, visuotinai taikomas funkcijas, pvz. (B) taikomųjų programų kūrėjai klientui ir serveriui perduoda taikomąsias eilutes. Spektras susijęs tik su pirmuoju (A). Kyla klausimas, ar yra susitarimų dėl (B). Yra. Tai apima parametrų grupavimą abėcėlės tvarka ir jų atskyrimą nuo daugelio standartui tinkamų tipų antraščių (A). Naudojant priešdėlį „X-“ arba „X-ACME-“ (B) yra patogus ir teisėtas ir neprieštarauja (A). Kuo daugiau pardavėjų nustoja naudoti „X-“ (A), tuo aiškiau jie tampa (B).

Pavyzdys:
„Google“ (kuri atlieka šiek tiek svorio įvairiose standartizacijos įstaigose) - šiandien, 20141102 šiuo nedideliu mano atsakymo pakeitimu - šiuo metu naudoja „X-Mod-Pagespeed“, nurodydama savo Apache modulio, dalyvaujančio transformuojant šį atsakymą, versiją. Ar kas nors tikrai siūlo „Google“ naudoti „Mod-Pagespeed“ be „X-“ ir / arba paprašyti IETF palaiminti jo naudojimą?

Santrauka:
Jei naudojate pasirinktines HTTP antraštes (kaip kartais tinkamas slapukus) savo duomenų perdavimui į savo serverį, ir šios antraštės aiškiai nenumatytos naudoti už jūsų paraiškos konteksto, tarp jų priskiriama „X-“ arba „X-FOO- „prefiksas yra pagrįsta ir standartinė konvencija.

422
28 окт. atsakymas, pateiktas cweekly spalio 28 d 2013-10-28 19:39 '13, 19:39, 2013-10-28 19:39

HTTP antraštių formatas yra apibrėžtas HTTP specifikacijoje. Kalbėsiu apie HTTP 1.1, kuriam skirta RFC 2616 specifikacija. 4.2 skirsnyje „Pranešimų antraštės“ apibrėžiama bendra antraštės struktūra:

  message-header = field-name ":" [ field-value ] field-name = token field-value = *( field-content | LWS ) field-content = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, separators, and quoted-string> 

Šis apibrėžimas grindžiamas dviem pagrindiniais principais: žetonų ir TEKSTO. Abu yra apibrėžti Pagrindinių taisyklių 2.2 skirsnyje. Ženklas:

  token = 1*<any CHAR except CTLs or separators> 

Savo ruožtu, remdamiesi CHAR, CTL ir separatoriais:

  CHAR = <any US-ASCII character (octets 0 - 127)> CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)> separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT 

TEKSTAS:

  TEXT = <any OCTET except CTLs, but including LWS> 

Kai LWS yra linijinė tuščia erdvė, kurios apibrėžimas nebus rodomas, ir OCTET:

  OCTET = <any 8-bit sequence of data> 

Prie apibrėžimo pridedama pastaba:

 The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047 [14]. 

Taigi, dvi išvados. Pirma, aišku, kad pavadinimo pavadinimas turėtų būti sudarytas iš ASCII simbolių pogrupio - raidžių ir skaitmenų, kai kurių skyrybos ženklų, o ne daug kitų. Antra, antraštės reikšmės apibrėžtyje nėra jokių apribojimų, kurie riboja jos ASCII arba neįtraukia 8 bitų simbolių: jis aiškiai susideda iš oktetų, ir draudžiami tik kontroliniai ženklai (atkreipkite dėmesį, kad CR ir LF yra kontrolė). Be to, TEKSTO išleidimo komentaras reiškia, kad oktetai turi būti interpretuojami kaip ISO-8859-1 ir kad yra kodavimo mechanizmas (kuris, beje, yra baisus), skirtas simboliams užkoduoti už šio kodavimo ribų.

Taigi, norint atsakyti į @BalusC, yra visiškai aišku, kad pagal specifikaciją antraštės reikšmės atitinka ISO-8859-1. Siunčiau aukštos kokybės 8859-1 simbolius (ypač kai kuriuos akcentuotus balsius, kaip vartojama prancūzų kalba) Tomcat antraštėje ir teisingai juos aiškinau „Firefox“, todėl tam tikru mastu jis veikia tiek praktikoje, tiek teoriškai (nors tai buvo Vietovė, kurioje yra URL, ir šie simboliai nėra teisėti URL, todėl jis buvo neteisėtas, bet pagal kitą taisyklę!).

Tačiau nenoriu pasikliauti ISO-8859-1, veikiančiu visuose serveriuose, tarpiniuose serveriuose ir klientuose, todėl norėčiau laikytis ASCII kaip gynybos programavimo.

57
25 авг. Atsakyti Tom Anderson rugpjūčio 25 d 2010-08-25 22:49 '10, 10:49 PM 2010-08-25 22:49

Antraštės lauko pavadinimo registras yra apibrėžtas RFC3864 ir nieko nėra ypatingas su „X“.

Kiek galiu pasakyti, nėra rekomendacijų dėl privačių išlaidų kategorijų; kyla abejonių, venkite jų. Arba žiūrėkite HTTP išplėtimo sistemą ( RFC 2774 ).

Būtų įdomu sužinoti daugiau apie naudojimą; Kodėl informacija negali būti pridėta prie pranešimo kūno?

15
25 авг. Atsakymą pateikė Julian Reschke rugpjūčio 25 d. 2010-08-25 09:44 '10 ne 9:44 2010-08-25 09:44

Keičiant arba pridedant papildomų HTTP antraščių, yra puiki priemonė derinant kodą, jei nieko nėra.

Kai URL užklausa grąžina peradresavimą arba vaizdą, nėra html puslapio, kuris laikinai įrašytų derinimo kodo rezultatus, bent jau tokį, kuris nėra rodomas naršyklėje.

Vienas iš būdų yra įrašyti duomenis į vietinį žurnalo failą ir peržiūrėti šį failą vėliau. Kitas yra laikinas HTTP antraštių papildymas, atspindintis ištaisytus duomenis ir kintamuosius.

Aš reguliariai įtraukiu papildomas HTTP antraštes, pvz., X-fubar-somevar: arba X-testing-someresult: viską patikrinti ir radome daug klaidų, kurių kitu atveju būtų sunku stebėti.

14
04 июля '11 в 12:29 2011-07-04 12:29 atsakymą pateikė g1smd liepos 4 d. 11 d. 12:29 2011-07-04 12:29

RFC6648 rekomenduoja pasiūlyti, kad jūsų pasirinktinė antraštė „gali tapti standartizuota, viešai prieinama, paprastai įdiegta arba naudojama daugelyje diegimų “. Todėl jis nerekomenduoja prieš jį pridėti „X-“ ar panašių konstrukcijų.

Tačiau yra išimtis: "kai labai mažai tikėtina, kad [jūsų pavadinimas] bus standartizuotas." Tokių „specifinių ir asmeninio naudojimo“ antraštių atveju RFC sako, kad vardų sritis, pvz., Tiekėjo prefiksas, yra pagrįsta.

2
24 июля '18 в 16:50 2018-07-24 16:50 atsakymą pateikė Edward Brey, liepos 24 d., 18 val., 16:50, 2018-07-24 16:50

Kiti klausimai apie „ žymes arba Užduoti klausimą