අභිරුචි HTTP ශීර්ෂයන්: නම් කිරීමේ සම්මුතීන්

1130

අපගේ පරිශීලකයින් කිහිපදෙනෙකු අප වෙත එවන ඉල්ලීම්වල HTTP ශීර්ෂයන් හෝ අපගේ API වෙතින් ලැබෙන ප්‍රතිචාර පවා ඔවුන්ගේ ගිණුමට සාපේක්ෂව දත්ත ඇතුළත් කරන ලෙස අපෙන් ඉල්ලා ඇත. නම් කිරීම , ආකෘතිය ... යනාදී වශයෙන් අභිරුචි HTTP ශීර්ෂ එකතු කිරීමේ පොදු සම්මුතිය කුමක්ද?

එසේම, ඔබ පැකිලී ගිය මේවායේ ඕනෑම ස්මාර්ට් භාවිතයක් වෙබයේ පළ කිරීමට නිදහස් වන්න; ඉලක්කයක් ලෙස එහි ඇති හොඳම දේ භාවිතා කරමින් අපි මෙය ක්‍රියාත්මක කිරීමට උත්සාහ කරමු :)

http http-headers

— ජූලියන් ජෙනෙස්ටොක්ස්
source

26

ෆයර්වෝල් වලට ප්‍රතිචාර ශීර්ෂ ක්ෂේත්‍ර ඉවත් කළ හැකි බව මතක තබා ගන්න. සමහරු RFC 2616 හි සඳහන් නොවන සියල්ල ඉවත් කරති (1999 ජුනි, HTTP 1.1). නව ක්ෂේත්‍ර නොමැතිව සේවාදායකයාගේ පැත්ත තවමත් භාවිතා කළ යුතුය.

— stesch

8

HTTP S භාවිතා කරන විට @stesch හි අදහස් දැක්වීම අදාළ නොවන බව සලකන්න .

— code_dredd

1

@Code_dredd විසින් කරන ලද ප්‍රකාශය නාගරික පුරාවෘත්තයක් බව සලකන්න. ෆයර්වෝල් වලට HTTPS අන්තර්ගතය පෙරීමට හැකිය. Howtoforge.com/filtering-https-traffic-with-squid and watchguard.com/help/docs/wsm/xtm_11/en-us/content/en-us/…

— stesch

2

articlestesch ඔබේ ලිපිය මූලික වශයෙන් ප්‍රොක්සිය මයිටම් එකකට සමාන දෙයක් බවට හරවන බැවින් (එය සංකේතාත්මක සේවාදායක සම්බන්ධතාවයක් ගෙන පසුව නව එකක් සාදයි) එවිට ඔබට ඕනෑම දෙයක් කළ හැකි බව සහතිකයි, නමුත් එම කරුණ ප්‍රොක්සි හි PoV b / වෙතින් සංකේතනය කිරීම ප්‍රතික්ෂේප කරයි. c එය සේවාදායකයාගේ අන්තර්ගතය විකේතනය කරයි. එවැනි අවස්ථාවකදී, ප්‍රොක්සි හි PoV වෙතින්, එය මූලික වශයෙන් ඔබ පළමු ස්ථානයේ HTTPS භාවිතා

— නොකළාක් මෙනි

1184

නිර්දේශ ඇත විය "X-" සමග තම නම ආරම්භ කිරීමට. උදා X-Forwarded-For, X-Requested-With. RFC 2047 හි 5 වන වගන්තියේ ද මෙය සඳහන් වේ .

යාවත්කාලීන 1 : සම්මත නොවන ශීර්ෂයන් සඳහා "X-" උපසර්ගය භාවිතා කිරීමේ නිර්දේශය අවලංගු කිරීම සඳහා පළමු ජුනි 1 වන දින IETF කෙටුම්පත පළ කරන ලදී . හේතුව, “X-” සමඟ උපසර්ගගත කර ඇති සම්මත නොවන ශීර්ෂයන් සම්මත වූ විට, “X-” උපසර්ගය ඉවත් කිරීමෙන් පසුපසට ගැළපුම බිඳ වැටෙන අතර, යෙදුම් ප්‍රොටෝකෝලයන් නම් දෙකටම සහය දැක්වීමට බල කරයි (උදා: සහ දැන් සමාන වේ). එබැවින්, නිල නිර්දේශය වන්නේ "X-" උපසර්ගය නොමැතිව ඒවා සංවේදීව නම් කිරීමයි .x-gzipgzip

යාවත්කාලීන 2 : 2012 ජුනි මාසයේදී “X-” උපසර්ගය භාවිතා කිරීම සඳහා වූ නිර්දේශය අවලංගු කිරීම RFC 6648 ලෙස නිල බවට පත්ව ඇත . අදාළ කරුණු පහත දැක්වේ:

3. නව පරාමිතීන් නිර්මාපකයින් සඳහා නිර්දේශ

...

ඔවුන්ගේ පරාමිති නාම "X-" හෝ ඒ හා සමාන ඉදිකිරීම් සමඟ උපසර්ග නොකළ යුතුය.

4. කෙටුම්පත් නිර්මාණකරුවන් සඳහා නිර්දේශ

...

"X-" උපසර්ගයක් හෝ ඒ හා සමාන ඉදිකිරීම් සහිත පරාමිතීන් ලියාපදිංචි වීම තහනම් නොකළ යුතුය.

“X-” උපසර්ගයක් හෝ ඒ හා සමාන ඉදිකිරීම් සහිත පරාමිතියක් තේරුම්ගත නොහැකි බව නියම නොකළ යුතුය.

“X-” උපසර්ගයක් හෝ ඒ හා සමාන ඉදිකිරීම් නොමැති පරාමිතියක් ප්‍රමිතිගත ලෙස තේරුම් ගත යුතු යැයි නියම නොකළ යුතුය.

"SHOULD NOT" ("අධෛර්යමත්") "MUST NOT" ("තහනම්") ට සමාන නොවන බව සලකන්න, එම මූල පදවල තවත් පිරිවිතරයක් සඳහා RFC 2119 ද බලන්න . වෙනත් වචන වලින් කිවහොත්, ඔබට "X-" උපසර්ග ශීර්ෂයන් දිගටම භාවිතා කළ හැකිය, නමුත් එය තවදුරටත් නිල වශයෙන් නිර්දේශ කර නොමැති අතර ඒවා අනිවාර්යයෙන්ම ඒවා පොදු ප්‍රමිතියක් ලෙස ලේඛනගත නොකරනු ඇත.

සාරාංශය :

නිල නිර්දේශය වන්නේ “X-” උපසර්ගය නොමැතිව ඒවා බුද්ධිමත්ව නම් කිරීමයි
ඔබට "X-" උපසර්ග ශීර්ෂයන් දිගටම භාවිතා කළ හැකිය, නමුත් එය තවදුරටත් නිල වශයෙන් නිර්දේශ කර නොමැති අතර ඒවා අනිවාර්යයෙන්ම ඒවා පොදු ප්‍රමිතියක් ලෙස ලේඛනගත නොකරනු ඇත

— BalusC
source

308

වෘත්තීය මලල ක්‍රීඩකයන් ලෙස කිසි විටෙකත් අවසන් නොවන බොහෝ ළමයින් සිටිනවා සේම, බොහෝ අභිරුචි ශීර්ෂයන් කිසි විටෙකත් ප්‍රමිතීන් ලෙස අවසන් නොවේ. මම "X-" ඒවා මත තබා ගැනීමට නැඹුරු වෙමි.

— ජී-මැක්

20

@ ජී-මැක් එකඟ විය. ඇත ඒ නිසා සම්මත අවසන් නොවන බව බොහෝ සිරිත් ශීර්ෂ. දේ කරන බව කිහිපයක්, එය ඔබේ කේතය පමණක් සංස්කරණය කිරීමට පහසුය if (header == "x-gzip")කිරීමට if (header == "x-gzip" || header == "gzip"). ඔබගේ ප්‍රතිසමයට අනුව, මෙන්න තවත් දෙයක්: එය මිලිටරිය කියන්නාක් මෙනි, "අනේ, යමෙකු පුද්ගලික සිට ජෙනරාල් දක්වා වෙනස් කිරීම කරදරකාරී ය. එබැවින් මෙතැන් සිට ඔබ සැවොම ජෙනරාල්වරු ය. දැන් අපට එතරම් වැඩක් කිරීමට අවශ්‍ය නැත"

— කෝල් ජොන්සන්

24

OleColeJohnson එම ප්‍රතිසමය ක්‍රියාත්මක වේදැයි විශ්වාස නැත. මෙහි ඇති ගැටළුව නම් ඔබට නම වෙනස් කළ හැකි කේන්ද්‍රීය ලක්ෂ්‍යයක් නොමැති වීමයි. X-gzip අපේක්ෂා කරන සෑම කේතයක්ම දැන් වෙනස් කළ යුතුය, නැතහොත් නව ශීර්ෂයට අමතරව පැරණි ශීර්ෂකය දිගටම භාවිතා කළ යුතුය. එය නේවාසික විදේශ ව්යවහාර මුදල් 6648. සමග යන්න වඩාත් තියෙන්නේ

— විනෝද්

4

In විනෝද් ඔව්. එය අර්ථවත් කරයි, නමුත් යෝජිත ප්‍රමිතීන් බොහෝමයක් ඇත, එය කිසි දිනක ආලෝකය නොපෙනේ. ගොනු වර්ග සඳහා, විශ්වාසයි; X-උපසර්ගය අතහරින්න . මම එයට විරුද්ධයි, නමුත් ඉදිරියට ගොස් එය කරන්න. OTOH ශීර්ෂයන් සඳහා, එය අතහරින්න එපා. එය බැලීමට හා යෑමට පහසු කරයි, "ඔහ්, එය සම්මත නොවන ය; මට එය නොසලකා හැරිය හැකිය" එදිරිව "එම සම්මත නොවන X-ශීර්ෂයන් ඇත, පසුව මා හඳුනා නොගත් එකක් තිබේ; මට එය ආරක්ෂිතව නොසලකා හැරිය හැකිද?"

— කෝල් ජොන්සන්

21

Cweekly ගේ පිළිතුරේ ස්වරය අනවශ්‍ය ලෙස ආරක්ෂාකාරී වුවද, ඔහු නිවැරදි යැයි මම විශ්වාස කරමි, ඔහුගේ අදහස මෙම විවරණ පොතේ දක්වා ඇති ගැටළුව විසඳයි. කෙටියෙන් කිවහොත්, ශීර්ෂ පා "යක්“ උපාධි ”කරයිද නැද්ද යන්න හඳුනා ගැනීමට උත්සාහ නොකරන්න; ඒ වෙනුවට එය පුද්ගලික හෝ පොදු ශීර්ෂයක්ද යන්න තීරණය කරන්න (යෙදුම්-විශේෂිත හෝ "සාමාන්‍ය" / "ගෝලීය"). පුද්ගලික ශීර්ෂයන් සඳහා, X-පොදු ශීර්ෂයන් සමඟ ගැටුමක් ඇති නොවන බවට විකල්පයක් ලෙස භාවිතා කරන්න (පොදු ශීර්ෂයන් සමඟ කටයුතු කරන RFC6648 ට ස්තූතියි), ඊට අමතරව අනිවාර්යයෙන්ම අත්තනෝමතික පෞද්ගලික උපසර්ගයක් භාවිතා කරන්න. පොදු ශීර්ෂයන් සඳහා, X-කිසිදු තත්වයක් යටතේ භාවිතා නොකරන්න .

— tne

539

ප්‍රශ්නය නැවත කියවීමකි. අසන ලද සත්‍ය ප්‍රශ්නය CSS දේපලවල විකුණුම් උපසර්ගයන්ට සමාන නොවේ, එහිදී අනාගතයේ සනාථ කිරීම සහ විකුණුම්කරුවන්ගේ සහාය සහ නිල ප්‍රමිතීන් ගැන සිතීම සුදුසු වේ. අසන ලද සත්‍ය ප්‍රශ්නය URL විමසුම් පරාමිති නාම තෝරා ගැනීමට වඩා සමාන ය. ඒවා මොනවාදැයි කිසිවෙකු ගණන් ගත යුතු නැත. නමුත් අභිරුචි ඒවා නම් කිරීම පරතරය පරිපූර්ණ වලංගු - සහ පොදු සහ නිවැරදි - කළ යුතු දෙයකි.

තාර්කිකත්වය:
එය සංවර්ධකයින් අතර අභිරුචි, යෙදුම්-විශේෂිත ශීර්ෂයන් සඳහා වන සම්මුතීන් ගැන ය - “ ඔවුන්ගේ ගිණුමට අදාළ දත්ත ” - වෙළෙන්දන්, ප්‍රමිති ආයතන හෝ තෙවන පාර්ශවයන් විසින් ක්‍රියාත්මක කළ යුතු ප්‍රොටෝකෝල සමඟ කිසිදු සම්බන්ධයක් නැති, සංවර්ධකයා හැර. ප්‍රශ්නයක් නම්, සේවාදායකයන්, ප්‍රොක්සි හෝ සේවාදායකයින් විසින් වෙනත් අපේක්ෂිත භාවිතයක් ඇති ශීර්ෂ නාම වලින් වැළකී සිටීමයි. මෙම හේතුව නිසා, ලබා දී ඇති "X-Gzip / Gzip" සහ "X-Forwarded-For / Forwarded-For" උදාහරණ moot වේ. යූආර්එල් විමසුම් පරාමිති නම් කිරීමේ සම්මුතීන්ට සමාන පුද්ගලික API එකක සන්දර්භය තුළ ඇති සම්මුතීන් පිළිබඳව පැන නගින ප්‍රශ්නයයි. එය මනාප සහ නම පරතරය පිළිබඳ කාරණයකි; "X" නොමැතිව ඕනෑම ප්‍රොක්සියක් හෝ වෙළෙන්දෙකු විසින් "X-ClientDataFoo" සඳහා සහය දැක්වීම ගැන සැලකිලිමත් වේ.

"X-" උපසර්ගය පිළිබඳ විශේෂ හෝ ඉන්ද්‍රජාලික කිසිවක් නොමැත, නමුත් එය අභිරුචි ශීර්ෂයක් බව පැහැදිලි කිරීමට එය උපකාරී වේ. ඇත්ත වශයෙන්ම, RFC-6648 සහ වෙනත් අය "X-" උපසර්ගයක් භාවිතා කිරීම සඳහා නඩුව ශක්තිමත් කිරීමට උපකාරී වේ, මන්ද - HTTP සේවාදායකයින්ගේ සහ සේවාදායකයන්ගේ වෙළෙන්දන් උපසර්ගය අතහැර දැමූ විට - ඔබේ යෙදුම්-විශේෂිත, පුද්ගලික-ඒපීඅයි, පුද්ගලික-දත්ත- නිල වෙන්කර ඇති ශීර්ෂ නාම කුඩා සංඛ්‍යාවක් සමඟ නාම-අභ්‍යවකාශ isions ට්ටනයට එරෙහිව සම්මත යාන්ත්‍රණය වඩාත් හොඳින් පරිවරණය වෙමින් පවතී. එයින් කියැවෙන්නේ මගේ පෞද්ගලික මනාපය සහ නිර්දේශය තවත් පියවරක් ඉදිරියට ගෙන ගොස් උදා: "X-ACME-ClientDataFoo" (ඔබේ විජට් සමාගම "ACME" නම්) කරන්න.

IMHO IETF පිරිවිතර OP හි ප්‍රශ්නයට පිළිතුරු දීමට ප්‍රමාණවත් නොවන බැවින් එය සම්පූර්ණයෙන්ම වෙනස් භාවිත අවස්ථා අතර වෙනස හඳුනා ගැනීමට අපොහොසත් වේ: (අ) වෙළෙන්දෝ එක් අතකින් “Forwarded-For” වැනි ගෝලීය වශයෙන් අදාළ වන නව අංග හඳුන්වා දීම, එදිරිව (B) යෙදුම් සංවර්ධකයින් විසින් සේවාදායකයාට සහ සේවාදායකයට / වෙතින් යෙදුම්-විශේෂිත නූල් පසු කරයි. පිරිවිතරයට අදාළ වන්නේ කලින් (අ) සමඟ පමණි. මෙහි ඇති ප්‍රශ්නය වන්නේ (බී) සඳහා සම්මුතීන් තිබේද යන්නයි. ඒ තියෙන්නේ. ඒවාට පරාමිතීන් අකාරාදී පිළිවෙලට කාණ්ඩගත කිරීම හා බොහෝ ප්‍රමිතිවලට අදාළ (A) වර්ගයේ ශීර්ෂයන්ගෙන් වෙන් කිරීම ඇතුළත් වේ. "X-" හෝ "X-ACME-" උපසර්ගය භාවිතා කිරීම (B) සඳහා පහසු සහ නීත්‍යානුකූල වන අතර (A) සමඟ ගැටෙන්නේ නැත. (A) සඳහා "X-" භාවිතා කිරීම වැඩි වැඩියෙන් වෙළෙන්දෝ නතර කරන තරමට (B) අය වඩාත් පිරිසිදු ලෙස වෙනස් වේ.

උදාහරණය:
ගූගල් (විවිධ ප්‍රමිතිවල තරමක් බර උසුලන අය) - අද වන විට, 20141102 මගේ පිළිතුරට මෙම සුළු සංස්කරණයෙහි - දැනට ඔවුන්ගේ අපාචේ මොඩියුලයේ අනුවාදය දැක්වීමට "එක්ස්-මොඩ්-පේජ්පීඩ්" භාවිතා කරයි. දී ඇති ප්‍රතිචාරයක් පරිවර්තනය කිරීමට සම්බන්ධ වේ. ගූගල් විසින් "X-" නොමැතිව "මොඩ්-පේජ්පීඩ්" භාවිතා කළ යුතු යැයි කිසිවෙකු යෝජනා කරනවාද?

සාරාංශය:
ඔබේ සේවාදායකය වෙත / වෙතින් දත්ත යැවීම සඳහා ඔබ ඔබේ යෙදුම තුළ අභිරුචි HTTP ශීර්ෂයන් (කුකීස් සඳහා සමහර විට සුදුසු විකල්පයක් ලෙස) භාවිතා කරන්නේ නම්, සහ මෙම ශීර්ෂයන් පැහැදිලිවම, ඔබේ සන්දර්භයෙන් පිටත කිසි විටෙකත් භාවිතා කිරීමට අදහස් නොකෙරේ. යෙදුම, ඒවා "X-" හෝ "X-FOO-" උපසර්ගයකින් නම් කිරීම සාධාරණ හා පොදු සම්මුතියකි.

— cweekly
source

55

මගේ පිළිතුරේ පහත් අයෙකුට මගේ පිළිතුරේ කුමන කොටස විරුද්ධ විය හැකිදැයි පැහැදිලි කළ හැකි නම් මම එය අගය කරමි. මගේ කීර්ති නාමය ගැන මම එතරම් තැකීමක් නොකරමි, නමුත් මම අවංකවම කුතුහලයෙන් සිටිමි. එකඟ නොවීම පවතින්නේ කොහේද? ස්තූතියි.

— cweekly

57

ඔබගේ පිළිතුරට මම සම්පුර්ණයෙන්ම එකඟ වන අතර අසන ලද සත්‍ය ප්‍රශ්නයට පිළිතුරු සපයන එකම පිළිතුර එයයි. අපි මෙහි කතා කරන්නේ අභිරුචි, යෙදුම්-විශේෂිත ශීර්ෂයන් ගැන, කිසි විටෙකත් HTTP ප්‍රමිතීන්ට අනුව ප්‍රමිතිකරණය නොකළ යුතුය. මිනිසුන් භාවිතා කිරීමට නැඹුරු වන පොදු සම්මුතියක් තිබේද? (සමහර විට ඒවා "_" සමඟ උපසර්ග කිරීම වැනි? එනම්: ("_ClientDataFoo")

— මාර්තු

15

ස්තූතියි මාර්චි, ඔව්, පිළිගත් පිළිතුර අසන ලද ප්‍රශ්නයට පිළිතුරු සපයන්නේ නැත. සම්මත නොවන (නමුත් සාමාන්‍ය) ශීර්ෂයන් සඳහා "X-" උපසර්ගය අයිඊටීඑෆ් ක්ෂය කිරීම කිසි විටෙකත් ප්‍රමිතිගත නොවන අභිරුචි යෙදුම්-විශේෂිත ශීර්ෂයන්ට අදාළ නොවේ. ඔබේ ප්‍රශ්නයට පිළිතුරු සැපයීම සඳහා, මගේ මතය හා අත්දැකීම් අනුව (අවුරුදු 16 ක වෙබ් දේව්), හොඳම සම්මුතිය වන්නේ ඉහත සඳහන් කළ “X-ACME-ClientData” භාවිතා කිරීමයි. "X-" bc එය සම්මත නොවේ (එසේම එය කිසි විටෙකත් නොවනු ඇත, එබැවින් IETF ක්ෂය කිරීම මෙහි වැදගත් වේ), "ACME-" එය ඔබේ "ACME" සමාගමට හෝ විශේෂිත යෙදුමට නම් කිරීමට, සහ "ClientData" ඕනෑම දෙයක් විය හැකිය ඔබ කැමති අර්ථකථන නාමය. :)

— cweekly

6

Ar ඩැරල්මිලර් ... එබැවින් X-ACMECO-WIDGET-FOO භාවිතා කිරීම නිර්දේශ කිරීම. OP ගේ ප්‍රශ්නය සඳහා X- භාවිතා කිරීම RFC-6648 සහ ඒ හා සමාන ප්‍රතිවිරෝධතා නොවන බව මම අවධාරනය කරමි. ඔබ වෙනත් ජනතාවගේ ව්‍යාපෘති සඳහා රාමුවක්, පුස්තකාලයක් හෝ මොඩියුලයක් සපයන වෙළෙන්දෙකු නම්, එය වෙනස් කතාවක් වන අතර, සෑම අතින්ම එම RFC ටී ට අනුගමනය කරන්න. යෙදුම්-විශේෂිත ශීර්ෂ නම් කිරීමේ සම්මුතීන් සම්පූර්ණයෙන්ම පුද්ගලික ඒපීඅයි වේ. ඔවුන් "අනෙක් සියල්ලන්ගේ" නම් සමඟ ගැටෙන්නේ කෙසේද? ඒවා කාගේද?

— cweekly

11

RFC තර්කනය තේරුම් ගැනීමට මට අවංකවම කුඩා කරදරයක් තිබේ. පරාමිතිය ප්‍රමිතිගත කර ඇත්නම් සහ x- හා x- නොවන අනුවාදයන් ඇති බව පිළිගත යුතුය. එය ගැටළුවක් වන්නේ x- හා x- නොවන අනුවාද වල හැසිරීම සමාන නම් පමණි. මගේ API වෙත "වෙනුවෙන්" ශීර්ෂයක් එක් කිරීමට මම බලා සිටින නිසා මම මෙහි පැකිලී ගියෙමි. එය යම් දිනෙක ප්‍රසිද්ධ විය හැකිය (එය සාමාන්‍ය ආකාරයේ භාවිතයක් ලෙස). මම "On-Behalf-Of" භාවිතා කර යම් දිනෙක ඔවුන් එය සම්මත ශීර්ෂයක් ලෙස එකතු කරන්නේ නම්, මගේ අර්ථ නිරූපණය ප්‍රමිතිගත ඒවාට සමාන වනු ඇති අවාසි මොනවාද?

— fool4jesus

62

HTTP ශීර්ෂ සඳහා ආකෘතිය HTTP පිරිවිතරයෙන් අර්ථ දක්වා ඇත. මම HTTP 1.1 ගැන කතා කරන්නෙමි, ඒ සඳහා පිරිවිතර RFC 2616 වේ. 4.2, 'පණිවිඩ ශීර්ෂයන්' හි, ශීර්ෂයක සාමාන්‍ය ව්‍යුහය අර්ථ දක්වා ඇත:

   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>

මෙම අර්ථ දැක්වීම ප්‍රධාන කුළුණු දෙකක් මත රඳා පවතී, ටෝකන් සහ ටෙක්ස්ට්. දෙකම 2.2, 'මූලික රීති' හි අර්ථ දක්වා ඇත. ටෝකනය යනු:

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

අනෙක් අතට CHAR, CTL සහ බෙදුම්කරුවන් මත රැඳී සිටීම:

   CHAR           = <any US-ASCII character (octets 0 - 127)>

   CTL            = <any US-ASCII control character
                    (octets 0 - 31) and DEL (127)>

   separators     = "(" | ")" | "<" | ">" | "@"
                  | "," | ";" | ":" | "\" | <">
                  | "/" | "[" | "]" | "?" | "="
                  | "{" | "}" | SP | HT

TEXT යනු:

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

LWS යනු රේඛීය සුදු අවකාශයක් වන අතර, එහි අර්ථ දැක්වීම මම ප්‍රතිනිෂ්පාදනය නොකරමි, සහ OCTET යනු:

   OCTET          = <any 8-bit sequence of data>

අර්ථ දැක්වීම සමඟ සටහනක් ඇත:

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].

ඉතින්, නිගමන දෙකක්. පළමුවෙන්ම, ශීර්ෂ නාමය ASCII අක්ෂරවල උප කුලකයකින් සෑදිය යුතු බව පැහැදිලිය - අක්ෂර සංඛ්‍යා, සමහර විරාම ලකුණු, වෙනත් බොහෝ නොවේ. දෙවනුව, ශීර්ෂක අගය අර්ථ දැක්වීමේදී එය ASCII ට සීමා කරන හෝ බිටු 8 අක්ෂර බැහැර කරයි: එය පැහැදිලිවම අෂ්ටක වලින් සමන්විත වන අතර පාලක අක්ෂර පමණක් තහනම් කර ඇත (CR සහ LF පාලනයන් ලෙස සලකන බව සලකන්න). තව දුරටත්, ටෙක්ස්ට් නිෂ්පාදනය පිළිබඳ අදහස් දැක්වීමේදී ඇඟවෙන්නේ අෂ්ටක ISO-8859-1 ලෙස අර්ථ දැක්විය යුතු බවත්, එම කේතන ක්‍රමයෙන් පිටත අක්ෂර නිරූපණය කිරීම සඳහා කේතීකරණ යාන්ත්‍රණයක් (එය භයානක, අහම්බෙන්) ඇති බවත් ය.

එබැවින්, alBalusC වෙත විශේෂයෙන් ප්‍රතිචාර දැක්වීමට, පිරිවිතරයන්ට අනුව, ශීර්ෂ අගයන් ISO-8859-1 හි ඇති බව පැහැදිලිය. මම ටොම්කාට් වෙතින් ශීර්ෂ පා in යක් තුළ ඉහළ -8859-1 අක්ෂර (විශේෂයෙන් ප්‍රංශ භාෂාවෙන් භාවිතා කර ඇති ස්වර කිහිපයක්) යවා ඒවා ෆයර්ෆොක්ස් විසින් නිවැරදිව අර්ථ නිරූපණය කර ඇත්තෙමි, එබැවින් යම් තාක් දුරට මෙය ප්‍රායෝගිකව මෙන්ම න්‍යායෙන් ද ක්‍රියාත්මක වේ (මෙය URL එකක් අඩංගු ස්ථාන ශීර්ෂයක් වුවද, මෙම අක්ෂර URL වල නීත්‍යානුකූල නොවන බැවින් මෙය ඇත්ත වශයෙන්ම නීති විරෝධී ය, නමුත් වෙනත් රීතියක් යටතේ!).

එයින් කියැවෙන්නේ, මම සියලු සේවාදායකයන්, ප්‍රොක්සි සහ සේවාදායකයින් හරහා වැඩ කරන අයිඑස්ඕ -8859-1 මත විශ්වාසය නොතබන බැවින් ආරක්ෂිත වැඩසටහන්කරණයේ කාරණයක් ලෙස මම ASCII වෙත ඇලී සිටිමි.

— ටොම් ඇන්ඩර්සන්
source

3

නවතම HTTP පිරිවිතර RFC7230 පවසන්නේ "අලුතින් අර්ථ දක්වා ඇති ශීර්ෂ ක්ෂේත්‍ර ඔවුන්ගේ ක්ෂේත්‍ර අගයන් US-ASCII අෂ්ටක වලට සීමා කළ යුතු බවයි."

— රොබට් ටුපෙලෝ-ෂ්නෙක්

23

RFC6648 නිර්දේශ කරන්නේ ඔබේ අභිරුචි ශීර්ෂකය "ප්‍රමිතිගත, පොදු, පොදුවේ යෙදවූ හෝ බහු ක්‍රියාත්මක කිරීම් හරහා භාවිතා කළ හැකි" බවට උපකල්පනය කළ යුතු බවයි. එමනිසා, එය "X-" හෝ ඒ හා සමාන ඉදිකිරීම් සමඟ උපසර්ගය නොකිරීමට නිර්දේශ කරයි.

කෙසේ වෙතත්, "[ඔබේ ශීර්ෂකය] කවදා හෝ ප්‍රමිතිකරණය කිරීම අතිශයින්ම අසීරු වූ විට" ව්‍යතිරේකයක් ඇත. එවැනි “ක්‍රියාත්මක කිරීම-විශේෂිත සහ පුද්ගලික භාවිතය” ශීර්ෂයන් සඳහා, විකුණුම් උපසර්ගයක් වැනි නාම අවකාශයක් යුක්ති සහගත බව RFC පවසයි.

— එඩ්වඩ් බ්‍රේ
source

6

. සම්මත, පොදු, පොදුවේ යොදවා, හෝ බහු නිර්මාණයන් හරහා භාවිතා කළ හැකි වන පිණිස "මම මේ භාවිතය වීමට හේතුවක් ලබා දෙයි හිතන්නේ" RFC6648 ඔබ ඔබේ ශීර්ෂකය බව උපකල්පනය බව නිර්දේශ " X-. එය ඕනෑම උපසර්ගය නොමැතිව යම් දෙයක් standarized බවට පත් විය හැකි ඉඩකඩ වැඩි වන නිසා උපසර්ගය

— කොන්රාඩ්

On කොන්රාඩ් වෙනත් කෙනෙකුගේ සමාන ශීර්ෂයක් (ඔබේ ශීර්ෂකය නොවේ) ප්‍රමිතිගත විය හැකි යැයි ඔබ සිතන්නේ නම් , ඔබට ගැටුමක් වළක්වා ගත හැකිය X-, නමුත් එය මූලික වශයෙන් RFC6648 ට වඩා වෙනස් උපකල්පනයකි. RFC හි ව්‍යතිරේකය මඟින් අනාගත සම්මත ශීර්ෂයක් සහ වෙනත් වෙළෙන්දෙකුගේ ශීර්ෂයක් අතර ඇති විය හැකි ගැටුම් සඳහා හේතු වන අතර එමඟින් සමාගම් ඒකාබද්ධ කිරීම තුළින් ඔබේ තාක්‍ෂණය සමඟ ඒකාබද්ධ විය හැකිය.

— එඩ්වඩ් බ්‍රේ

17

වෙනස් කිරීම හෝ වඩාත් නිවැරදිව, අතිරේක HTTP ශීර්ෂ එකතු කිරීම වෙන කිසිවක් නොමැති නම් විශිෂ්ට කේත නිදොස් කිරීමේ මෙවලමකි.

යූආර්එල් ඉල්ලීමක් යළි-යොමුවීමක් හෝ රූපයක් ආපසු ලබා දෙන විට, නිදොස් කිරීමේ කේතයේ ප්‍රති results ල තාවකාලිකව ලිවීමට html “පිටුවක්” නොමැත - අවම වශයෙන් බ්‍රව්සරයක නොපෙනෙන එකක්වත් නැත.

එක් ප්‍රවේශයක් නම් දේශීය ලොග් ගොනුවකට දත්ත ලිවීම සහ එම ගොනුව පසුව බැලීම ය. තවත් දෙයක් නම් නිදොස්කරණය කරන ලද දත්ත සහ විචල්‍යයන් පිළිබිඹු කරමින් HTTP ශීර්ෂයන් තාවකාලිකව එකතු කිරීමයි.

මම නිතිපතා එක්ස්-ෆුබාර්-සොම්වර්: හෝ එක්ස්-ටෙස්ටිං-සමර්සල්ට් වැනි අමතර HTTP ශීර්ෂයන් එකතු කරමි.

— g1smd
source

2

ඔහු මෙම "ප්‍රමිතිය" භාවිතා කළ යුත්තේ ඇයි? ශීර්ෂයන් එකම ලෙස ක්‍රියා කරයි. "WHO_EVER_READS_THIS_IS_DUMB_" උපසර්ගය සමඟ වුවද ...

— ඇදහිය නොහැකි ජනවාරි

16

ශීර්ෂ ක්ෂේත්‍ර නාම ලේඛනය RFC3864 හි අර්ථ දක්වා ඇති අතර "X-" සමඟ විශේෂ කිසිවක් නොමැත.

මට කිව හැකි පරිදි, පුද්ගලික ශීර්ෂයන් සඳහා මාර්ගෝපදේශ නොමැත; සැකයෙන්, ඒවායින් වළකින්න. නැතහොත් HTTP ව්‍යාප්ති රාමුව ( RFC 2774 ) දෙස බලන්න .

භාවිතයේ වැඩි විස්තර තේරුම් ගැනීම සිත්ගන්නා සුළු වනු ඇත; පණිවිඩ ශරීරයට තොරතුරු එකතු කළ නොහැක්කේ ඇයි?

— ජූලියන් රෙස්ච්කේ
source

14

මම සමහර අභිරුචි ශීර්ෂයන් සලකා බැලීමට ප්‍රධාන හේතුව වන්නේ ශරීරය විග්‍රහ නොකර මට රවුටින් තීරණ ගැනීමට හැකි වීමයි ...

— රොස්වෙල්