HTTP (హెచ్‌టిటిపి)

వికీపీడియా నుండి
ఇక్కడికి గెంతు: మార్గసూచీ, వెతుకు

మూస:HTTP మూస:IPstack

హైపర్‌టెక్స్ట్ ట్రాన్సఫర్ ప్రోటోకాల్ (HTTP) అనేది పంపిణీ, సహకార, హైపర్‌మీడియా సమాచార వ్యవస్థల కోసం ఒక నెట్‌వర్కింగ్ ప్రోటోకాల్.[1] HTTP అనేది వరల్డ్ వైడ్ వెబ్ కోసం డేటా కమ్యూనికేషన్ యొక్క ఆధారంగా చెప్పవచ్చు.

HTTP ప్రాథమిక డెవలప్‌మెంట్‌లో ఇంటర్నెట్ ఇంజినీరింగ్ టాస్క్ ఫోర్స్ (IETF) మరియు వరల్డ్ వైడ్ వెబ్ కాన్సార్టియమ్‌లు సహకారాన్ని అందించాయి, చివరికి ఈ సహకారం వలన కొన్ని రిక్వెస్ట్ ఫర్ కామెంట్స్ (RFSలు) ప్రచురణ సాధ్యమైంది, వీటిలో ప్రస్తుతం వాడకంలో ఉన్న HTTP సంస్కరణ HTTP/1.1ను వివరించే RFC 2616 (జూన్ 1999) ప్రజాదరణ పొందింది.

సాంకేతిక పరిశీలన[మార్చు]

HTTP క్లయింట్-సర్వర్ కంప్యూటింగ్ నమూనాలో ఒక అభ్యర్థన-ప్రతిస్పందన ప్రోటోకాల్ వలె పనిచేస్తుంది. HTTPలో, ఉదాహరణకు ఒక వెబ్ బ్రౌజర్ ఒక క్లయింట్ వలె పనిచేస్తుంది, ఒక వెబ్ సైట్‌ను కలిగి ఉన్న ఒక కంప్యూటర్‌లో అమలు అవుతున్న ఒక అనువర్తనం ఒక సర్వర్ వలె పనిచేస్తుంది. క్లయింట్ ఒక HTTP అభ్యర్థన సందేశాన్ని సర్వర్‌కు సమర్పిస్తాడు. విషయాన్ని నిల్వ చేసే లేదా HTML ఫైళ్లు వంటి వనరుల ను అందించే లేదా క్లయింట్ తరపున ఇతర ఫంక్షన్‌లను అమలు చేసే సర్వర్ క్లయింట్‌కు ఒక ప్రతిస్పందన సందేశాన్ని పంపుతుంది. ఒక ప్రతిస్పందనలో అభ్యర్థన గురించి సంపూర్ణ స్థితి సమాచారం మరియు క్లయింట్ దాని సందేశంలో అభ్యర్థించిన ఏదైనా విషయాన్ని కలిగి ఉండవచ్చు.

ఒక క్లయింట్‌ను తరచూ ఒక వినియోగదారు ఏజెంట్ (UA) వలె సూచిస్తారు. ఒక వెబ్ క్రాలెర్ (స్పైడర్ ) అనేది క్లయింట్ లేదా వినియోగదారు ఏజెంట్ యొక్క సాధారణ రకానికి మరొక ఉదాహరణ.

HTTP ప్రోటోకాల్‌ను క్లయింట్‌లు మరియు సర్వర్‌ల మధ్య కమ్యూనికేషన్‌లను మెరుగుపర్చడానికి లేదా ప్రారంభించడానికి మధ్యంతర నెట్‌వర్క్ అంశాలను అనుమతించడానికి రూపొందించబడింది. అత్యధిక ట్రాఫిక్ గల వెబ్‌సైట్‌లు తరచూ ప్రతిస్పందన సమయాన్ని మెరుగుపర్చడానికి యదార్థ ఆధార సర్వర్ అని పిలవబడే సర్వర్ తరపున విషయాన్ని పంపిణీ చేసే వెబ్ క్యాషీ సర్వర్‌ల ద్వారా ప్రయోజనం పొందుతాయి. క్లయింట్‌లు మరియు సర్వర్‌ల మధ్య అభ్యర్థనలు మరియు ప్రతిస్పందనలపై ఆధారపడటం ద్వారా ఒక ప్రపంచవ్యాప్త రూటబుల్ చిరునామా లేని క్లయింట్‌లను ప్రైవేట్ నెట్‌వర్క్‌లో గుర్తించినప్పుడు, నెట్‌వర్క్ హద్దుల్లో HTTP ప్రాక్సీ సర్వర్‌లు సంభాషణకు దోహదపడతాయి.

HTTP అనేది ఇంటర్నెట్ ప్రోటోకాల్ సూట్ యొక్క నిర్మాణంలో రూపొందించిన ఒక అనువర్తన స్థాయి ప్రోటోకాల్. ప్రోటోకాల్ వివరణలు హోస్ట్ నుండి హోస్ట్‌కు డేటా బదిలీ కోసం ఒక విశ్వసనీయ బదిలీ స్థాయి ప్రోటోకాల్ వలె పేర్కొంటాయి.[2] ట్రాన్సమిషన్ కంట్రోల్ ప్రోటోకాల్ (TCP) అనేది ఈ విధానం కోసం ఉపయోగించే ఒక ప్రధాన ప్రోటోకాల్. అయితే, HTTP అనేది అవిశ్వసనీయ ప్రోటోకాల్‌లతో కూడా అనువర్తనాలను కలిగి ఉంది, ఉదాహరణకు సింపుల్ సర్వీస్ డిస్కవరీ ప్రోటోకాల్ (SSDP) వంటి పద్ధతిలో యూజర్ డాటాగ్రామ్ ప్రోటోకాల్ (UDP).

HTTP వనరులను యూనీఫారమ్ రిసోర్స్ ఐడెంటిఫియర్‌లు (URIలు)-లేదా, మరింత స్పష్టంగా, యూనీఫారమ్ రిసోర్స్ లొకేటర్‌లు (URLలు)-ద్వారా http లేదా https URI స్కీమ్‌ను ఉపయోగించుకుని నెట్‌వర్క్‌లో గుర్తించబడతాయి మరియు కనుగొనబడతాయి. URIలు మరియు హైపర్‌టెక్స్ట్ మార్కప్ లాంగ్వేజ్ (HTML)లు ఇంటర్నెట్‌లో హైపర్‌టెక్ట్స్ పత్రాలు అని పిలిచే ఒక అంతర్గతంగా అనుబంధించబడిన వనరుల వ్యవస్థను రూపొందించాయి, ఇది ఆంగ్ల భౌతిక శాస్త్రవేత్త టిమ్ బెర్నెర్స్-లీ 1990లో వరల్డ్ వైడ్ వెబ్ స్థాపనకు కారణమైంది.

HTTP (HTTP/1.0) యొక్క యదార్ధ సంస్కరణను HTTP/1.1 పునరుద్ధరించారు. HTTP/1.0 ప్రతి అభ్యర్థన-ప్రతిస్పందన లావాదేవీ కోసం అదే సర్వర్‌కు వేరొక అనుసంధానాన్ని ఉపయోగిస్తుంది, అయితే HTTP/1.1 దిగుమతి చేయడానికి ఉదాహరణకు పంపిణీ చేసిన పుటకు చిత్రాలను దిగుమతి చేయడానికి ఒక అనుసంధానాన్ని పలుసార్లు మళ్లీ మళ్లీ ఉపయోగిస్తుంది. కనుక HTTP/1.1 సంభాషణలు అత్యల్ప గోప్యతను కలిగి ఉంటుంది ఎందుకంటే దీనిలో ఉండే TCP అనుసంధానాల స్థాపన ఎక్కువగా ఉంటుంది.

చరిత్ర[మార్చు]

హైపర్‌టెక్స్ట్ అనే పదాన్ని టెడ్ నెల్సన్ పరిచయం చేశాడు, దీనికి ఇతను వానెవార్ బుష్ యొక్క సూక్ష్మచిత్రం ఆధారిత "మెమెక్స్" నుండి ప్రేరణ పొందాడు. టిమ్ బెర్నెర్స్-లీ మొట్టమొదటిగా "వరల్డ్‌వైడ్‌వెబ్" ప్రాజెక్ట్‌ను ప్రతిపాదించాడు - దీనినే ప్రస్తుతం వరల్డ్ వైడ్ వెబ్ అని పిలుస్తారు. బెర్నెర్స్-లీ మరియు అతని బృందం ఒక వెబ్ సర్వర్ మరియు ఒక టెక్ట్స్-ఆధారిత వెబ్ బ్రౌజర్ కోసం HTML మరియు సంబంధిత సాంకేతికతతో యదార్థ HTTP ప్రోటోకాల్‌ను కనిపెట్టారు. ప్రోటోకాల్ యొక్క మొట్టమొదటి సంస్కరణ GET అని పిలిచే ఏకైక పద్ధతిని కలిగి ఉంది, ఇది ఒక సర్వర్ నుండి ఒక పుటను అభ్యర్థిస్తుంది.[3] సర్వర్ నుండి ప్రతిస్పందన ఎల్లప్పుడూ ఒక HTML పుట వలె అందుతుంది.[4]

HTTP యొక్క మొట్టమొదటి పత్రబద్ధ సంస్కరణ HTTP V0.9 (1991). HTTP వర్కింగ్ గ్రూప్ (HTTP WG)ను 1995లో డేవ్ రాగెట్ నడిపించాడు మరియు ఒక భద్రతా ప్రోటోకాల్‌తో కలిపి ప్రోటోకాల్ విస్తారిత కార్యాచరణలు, విస్తారిత మంతనాలు, ఉత్తమ మెటా-సమాచారాలను విస్తరించాలని మరియు అదనపు పద్ధతులు మరియు శీర్షిక క్షేత్రాలను జోడించడం ద్వారా మరింత సౌకర్యవంతంగా చేయాలని భావించాడు.[5][6] RFC 1945 అధికారికంగా 1996లో HTTP V1.0ను పరిచయం చేయబడింది మరియు గుర్తింపు పొందింది.

HTTP WG 1995 డిసెంబరులో నూతన ప్రమాణాలను ప్రచురించాలని భావించింది[7] మరియు అప్పుడు అభివృద్ధిలో ఉన్న RFC 2068 (HTTP-NG అని పిలుస్తారు) ఆధారంగా పూర్వ ప్రధాన HTTP/1.1 కోసం మద్దతును 1996 ప్రారంభ కాలంలో ప్రధాన బ్రౌజర్ డెవలపర్లచే ఎక్కువగా ఆచరించబడ్డాయి. 1996 మార్చినాటికి, పూర్వ ప్రధాన HTTP/1.1 అనేది ఆరీనా,[8] నెట్‌స్కేప్ 2.0,[8] నెట్‌స్కేప్ నావిగేటర్ గోల్డ్ 2.01,[8] మోసాయిక్ 2.7,[citation needed] లెన్క్స్ 2.5[citation needed] మరియు ఇంటర్నెట్ ఎక్స్‌ప్లోరెర్ 3.0[citation needed]లో మద్దతు కలిగి ఉంది. నూతన బ్రౌజర్‌ల్లో తుది వినియోగదారు స్వీకరణ పెరిగింది. 1996 మార్చిలో, ఒక వెబ్ హోస్టింగ్ సంస్థ ఇంటర్నెట్‌లో ఉపయోగిస్తున్న 40% కంటే ఎక్కువ బ్రౌజర్‌లు HTTP 1.1ను ఉపయోగిస్తున్నట్లు పేర్కొంది.[citation needed] 1996 జూన్‌లో అదే వెబ్ హోస్టింగ్ సంస్థ దాని సర్వర్‌లను ప్రాప్తి చేస్తున్న మొత్తం బ్రౌజర్‌ల్లో 65% బ్రౌజర్‌లు HTTP/1.1ను ఉపయోగిస్తున్నట్లు పేర్కొంది.[9] RFC 2068 అనుగుణంగా పేర్కొన్న HTTP/1.1 ప్రమాణాన్ని అధికారికంగా 1997 జనవరిలో విడుదల చేశారు. HTTP/1.1 ప్రమాణానికి మెరుగుదలలు మరియు నవీకరణలను 1999 జూన్‌లో RFC 2616 పేరుతో విడుదల చేశారు.

HTTP సెషన్[మార్చు]

ఒక HTTP సెషన్ అనేది నెట్‌వర్క్ అభ్యర్థన-ప్రతిస్పందన లావాదేవీల ఒక క్రమంగా చెప్పవచ్చు. ఒక HTTP క్లయింట్ ఒక అభ్యర్థనను పంపుతుంది. ఇది ఒక హోస్ట్‌లో ఒక నిర్దిష్ట పోర్ట్‌కు ఒక ట్రాన్సమిషన్ కంట్రోల్ ప్రోటోకాల్ (TCP)ను ఏర్పాటు చేస్తుంది (సాధారణంగా పోర్ట్ 80; TCP మరియు UDP పోర్ట్ సంఖ్యల జాబితాను చూడండి). ఆ పోర్ట్‌లో ఉన్న ఒక HTTP సర్వర్ ఒక క్లయింట్ యొక్క అభ్యర్థన సందేశం కోసం వేచి ఉంటుంది. అభ్యర్థనను స్వీకరించిన తర్వాత, సర్వర్ "HTTP/1.1 200 OK" వంటి ఒక స్థితి సందేశాన్ని మరియు అభ్యర్థించిన వనరు, ఒక దోష సందేశం లేదా కొంత ఇతర సమాచారంతో దాని స్వంత విషయాన్ని వెనక్కి పంపుతుంది.[1]

అభ్యర్థన సందేశం[మార్చు]

అభ్యర్థన సందేశం కింది అంశాలను కలిగి ఉంటుంది:

  • అభ్యర్థన పంక్తి, GET /images/logo.png HTTP/1.1 వంటిది, ఇది సర్వర్ నుండి /images/logo.png అనే ఒక వనరును అభ్యర్థిస్తుంది
  • శీర్షికలు, Accept-Language: en వంటివి
  • ఒక ఖాళీ పంక్తి
  • ఒక వైకల్పిక సందేశ అంశం

అభ్యర్థన పంక్తి మరియు శీర్షికలు అన్ని <CR><LF>తో పూర్తి కావాలి (అంటే, ఒక లైన్ ఫీడ్ తర్వాత ఒక క్యారేజ్ రిటర్న్). ఖాళీ పంక్తి <CR><LF>ను మాత్రమే కలిగి ఉండాలి మరియు ఎటువంటి ఖాళీ ఉండరాదు.[10] HTTP/1.1 ప్రోటోకాల్‌లో, హోస్ట్ మినహా అన్ని శీర్షికలు వైకల్పికం.

RFC1945లో HTTP/1.0 వివరణకు ముందు HTTP క్లయింట్‌తో అనుకూలతను నిర్వహించడానికి సర్వర్‌లు మార్గం పేరు మాత్రమే గల ఒక అభ్యర్థన పంక్తిని ఆమోదించేవి.[11]

అభ్యర్థన పద్ధతులు[మార్చు]

టెల్‌నెట్‌ను ఉపయోగించి చేసిన ఒక HTTP అభ్యర్థన. అభ్యర్థన, ప్రతిస్పందన శీర్షికలు మరియు ప్రతిస్పందన విషయాలు ప్రముఖంగా ప్రదర్శించబడ్డాయి.

HTTP గుర్తించిన వనరు పై అవసరమైన చర్యను అమలు చేయడానికి సూచిస్తూ తొమ్మిది విధానాలను (కొన్నిసార్లు "వెర్బ్స్" అని పిలుస్తారు) పేర్కొంది. ఈ వనరు ముందే ఉన్న సమాచారాన్ని లేదా ఆకస్మికంగా రూపొందించబడిన సమాచారాన్ని సూచిస్తుందో అనే విషయం సర్వర్ అమలుపై ఆధారపడి ఉంటుంది. తరచూ, వనరు ఒక ఫైల్‌ను లేదా సర్వర్‌లో ఉన్న ఒక అమలు అయ్యే అంశం యొక్క ఫలితాన్ని అందిస్తుంది.

HEAD
ఒక GET అభర్థనకు సంబంధించిన దానికి సరిపోలే ప్రతిస్పందన కోసం అభ్యర్థిస్తుంది, కాని ప్రతిస్పందన విషయం ఉండదు. ఇది మొత్తం విషయాన్ని బదిలీ చేయవల్సిన అవసరం లేకుండా, ప్రతిస్పందన శీర్షికల్లో రాయబడిన మెటా సమాచారాన్ని తిరిగి పొందడానికి సౌలభ్యంగా ఉంటుంది.
GET
నిర్దిష్ట వనరు యొక్క ఒక నివేదనను అభ్యర్థిస్తుంది. GET ఉపయోగించే అభ్యర్థనలు (మరియు మరికొన్ని ఇతర HTTP విధానాలు) "తిరిగి పొందడానికి మినహా ఎటువంటి ప్రధాన చర్యను నిర్వహించబడదు".[1] ఈ భేదంపై W3C మార్గదర్శక సూత్రాలను ప్రచురించి ఇలా పేర్కొంది, "వెబ్ అనువర్తన రూపకల్పన తప్పక పైన పేర్కొన్న సూత్రాలకు అనుగుణంగా ఉండాలి, అలాగే సంబంధిత పరిమితులను కలిగి ఉండాలి."[12] కింది సురక్షిత విధానాలు చూడండి.
POST
ప్రాసెస్ చేయడానికి గుర్తించిన వనరుకు సమాచారాన్ని సమర్పిస్తుంది (ఉదా., ఒక HTML పత్రం నుండి). ఈ సమాచారం అభ్యర్థన అంశంలో చేర్చబడుతుంది. దీని ఫలితంగా నూతన వనరు రూపొందించబడవచ్చు లేదా ఇప్పటికే ఉన్న ఒక వనరును నవీకరించవచ్చు లేదా రెండు జరగవచ్చు.
PUT
నిర్దిష్ట వనరు యొక్క వివరణను అప్‌లోడ్ చేస్తుంది.
DELETE
నిర్దిష్ట వనరును తొలగిస్తుంది.
TRACE
స్వీకరించిన అభ్యర్థనను మళ్లీ పునరుద్ఘాటిస్తుంది, దీని వలన ఒక క్లయింట్ మధ్యంతర సర్వర్‌లు చేసిన మార్పులు లేదా చేర్పులను (ఏవైనా జరిగినట్లయితే) చూడవచ్చు.
OPTIONS
నిర్దిష్ట URLకు మద్దతు ఇచ్చే సర్వర్‌లోని HTTP విధానాలను అందిస్తుంది. దీనిలో ఒక నిర్దిష్ట వనరుకు బదులుగా '*'ను అభ్యర్థించడం ద్వారా ఒక వెబ్ సర్వర్ పంక్షనాలిటీని తనిఖీ చేయడానికి దీనిని ఉపయోగించవచ్చు.
CONNECT
అభ్యర్థన అనుసంధానాన్ని ఒక పారదర్శక TCP/IP ప్రవాహం వలె మారుస్తుంది, సాధారణంగా ఒక సాధారణ HTTP ఫ్రాక్సీ ద్వారా SSL గుప్తీకరించిన కమ్యూనికేషన్ (HTTPS)ను అందిస్తుంది.[13]
PATCH
దీనిని ఒక వనరుకు పాక్షిక సవరణలను అనువర్తించడానికి ఉపయోగిస్తారు.[14]

HTTP సర్వర్‌లు కనిష్టంగా GET మరియు HEAD విధానాలను అమలు చేయాల్సి ఉంటుంది[15] మరియు అవసరమైనప్పుడు, OPTIONS విధానాన్ని కూడా అమలు చేయాలి.[ఆధారం కోరబడినది]

సురక్షిత విధానాలు[మార్చు]

కొన్ని విధానాలను (ఉదాహరణకు, HEAD, GET, OPTIONS మరియు TRACE) సురక్షితం గా పేర్కొంటారు, అంటే వీటిని సమాచారాన్ని పొందడానికి మాత్రమే ఉపయోగిస్తారు మరియు ఇది సర్వర్ యొక్క స్థితిని మార్చవు. ఇంకా స్పష్టంగా చెప్పాలంటే, ఇవి లాగింగ్, క్యాషీంగ్, బ్యానర్ ప్రకటనలను అందించడం లేదా వెబ్ కౌంటర్‌ను పెంచడం వంటి సంబంధిత ప్రమాదరహిత ప్రభావాలు మినహా ఎటువంటి ఇతర ప్రభావాలను కలిగి ఉండవు. దీని వలన అనువర్తనం యొక్క స్థితితో సంబంధం లేకుండా ఏకపక్ష GET అభ్యర్థనలను రూపొందించడాన్ని సురక్షితంగా భావిస్తారు.

దీనికి విరుద్ధంగా, POST, PUT మరియు DELETE వంటి విధానాలను సర్వర్‌లో ఇతర ప్రభావాలకు లేదా ఆర్థిక లావాదేవీలు లేదా ఇమెయిల్ ప్రసారం వంటి ఇతర బాహ్య ప్రభావాలకు కారణమైన చర్యలు కోసం ఉపయోగిస్తారు. కనుక ఇటువంటి విధానాలను సాధారణంగా వెబ్ రోబోట్లు లేదా వెబ్ క్రాలర్‌లను సర్దుబాటు చేయడానికి ఉపయోగిస్తారు, ఇవి సందర్భం లేదా పరిణామాలతో సంబంధం లేకుండా అభ్యర్థనలు చేస్తాయి.

పేర్కొన్న GET అభ్యర్థనల భద్రతే కాకుండా, ఆచరణలో సర్వర్‌చే వాటి నిర్వహణ సాంకేతికంగా ఎటువంటి పరిమితులను కలిగి ఉండవు. కనుక, అజాగ్రత్త లేదా బుద్ధిపూర్వక ప్రోగ్రామింగ్ సర్వర్‌లో ప్రధాన మార్పులకు కారణం కావచ్చు. ఇది వెబ్ క్యాషింగ్, శోధన ఇంజిన్లు మరియు ఇతర స్వయంచాలక ఏజెంట్లకు సమస్యలను ఏర్పరిచే అవకాశం ఉన్న కారణంగా దీనిని ప్రోత్సహించరు, ఇది సర్వర్‌లో అనవసర మార్పులను చేయవచ్చు.

ఇంకా, TRACE, TRACK మరియు DEBUG వంటి విధానాలను కొంతమంది నిపుణులు 'అసురక్షితం'గా భావిస్తారు ఎందుకంటే వీటిని దాడి చేసే సమయంలో సమాచారాన్ని సేకరించడానికి లేదా భద్రతా నియంత్రణలను దాటవేయడానికి దాడిచేసే వ్యక్తులు ఉపయోగిస్తారు. టెనాబెల్ నెసస్ మరియు మైక్రోసాఫ్ట్ URLస్కాన్ వంటి భద్రతా సాఫ్ట్‌వేర్ పరికరాలు ఈ విధానాల ఉనికిని భద్రతా సమస్యలుగా పేర్కొంటాయి.

మార్పురహిత విధానాలు మరియు వెబ్ అనువర్తనాలు[మార్చు]

PUT మరియు DELETE విధానాలను మార్పురహితంగా పేర్కొంటారు, అంటే పలు సారూప్య అభ్యర్థనలు చేసినప్పటికీ, దాని ప్రభావం ఏకైక అభ్యర్థన ప్రభావం వలె ఉంటుంది. GET, HEAD, OPTIONS మరియు TRACE విధానాలను సురక్షితమైన, మార్పురహిత విధానాలు వలె కూడా పేర్కొంటారు, ఎందుకంటే HTTP అనేది ఒక ప్రత్యేక స్థితి లేని ప్రోటోకాల్.

విరుద్ధంగా, POST విధానం అనేది మార్పురహిత విధానం కావల్సిన అవసరం లేదు మరియు ఒక సమాన POST అభ్యర్థనను పలుసార్లు పంపడం వలన, మరిన్ని ప్రభావాలు కనిపించవచ్చు లేదా మరిన్ని ఇతర ప్రభావాలకు కారణం కావచ్చు (ఆర్థిక లావాదేవీలు వంటివి). కొన్ని సందర్భాల్లో, ఇది అవసరం కావచ్చు, కాని ఇతర సందర్భాల్లో ఇది యాదృచ్ఛికంగా సంభవించవచ్చు, అంటే ఒక వినియోగదారుకు వారి చర్య వలన మరొక అభ్యర్థన పంపబడుతుందని తెలియనప్పుడు లేదా వారు మొట్టమొదటి అభ్యర్థన విజయవంతమైందని తగిన సందేశం పొందలేన సమయాల్లో జరగవచ్చు. కొన్ని సందర్భాల్లో వెబ్ బ్రౌజర్‌లు ఒక పుటను మళ్లీ లోడ్ చేయడం వలన ఒక POST అభ్యర్థన మళ్లీ సమర్పించబడతుందని వినియోగదారులను హెచ్చరిస్తూ హెచ్చరిక వ్యాఖ్య పేటికలను ప్రదర్శించవచ్చు, ఇది ఒక POST అభ్యర్థనను ఒకసారి కంటే ఎక్కువ సమర్పించకూడదనే సందర్భాలను నిర్వహించే వెబ్ అనువర్తనంపై ఆధారపడి ఉంటుంది.

ఒక విధానం మార్పురహిత విధానమో కాదో ప్రోటోకాల్ లేదా వెబ్ సర్వర్ సూచించవని గమనించండి. ఒక GET లేదా ఇతర అభ్యర్థనలను అమలు చేయడం ద్వారా (ఉదాహరణకు) ఒక డేటాబేస్‌లో సమాచారాన్ని జోడించడం లేదా ఇతర మార్పుల చేసే చర్యను నిర్వహించేలా ఒక వెబ్ అనువర్తనాన్ని రూపొందించడం ఖచ్చితంగా సాధ్యమవుతుంది. అయితే ఈ గమనికను విమర్శించడం వలన, ఊహించని పరిణామాలకు దారి తీయవచ్చు, అంటే ఒక వినియోగదారు ఏజెంట్ సురక్షితం కానప్పటికీ, ఒకే అభ్యర్థనను పునరావృతం చేయడం సురక్షితంగా భావించవచ్చు.

స్థితి సంకేతాలు[మార్చు]

HTTP/1.0 మరియు తదుపరి వాటిలో, HTTP ప్రతిస్పందనలో మొట్టమొదటి పంక్తిని స్థితి పంక్తి గా పిలుస్తారు మరియు దీనిలో ఒక సంఖ్యా స్థాయి సంకేతం ("404" వంటివి) మరియు ఒక పాఠ్య హేతుబద్ధ అంశం ("Not Found" వంటివి) ఉంటాయి. వినియోగదారు ఏజెంట్ ప్రతిస్పందనను నిర్వహించే పద్ధతి ప్రధానంగా సంకేతంపై మరియు తర్వాత ప్రతిస్పందన శీర్షికలపై ఆధారపడి ఉంటుంది. అనుకూల స్థితి సంకేతాలను కూడా ఉపయోగించవచ్చు, వినియోగదారు ఏజెంట్ గుర్తించలేని ఒక సంకేతాన్ని పొందినట్లయితే, ప్రతిస్పందన యొక్క సాధారణ వర్గాన్ని గుర్తించడానికి ఇది సంకేతంలోని మొట్టమొదటి అంకెను ఉపయోగిస్తుంది.[16]

అలాగే, ప్రాథమిక హేతుబద్ధ అంశాలు సిఫార్సులు మాత్రమే మరియు వీటి స్థానంలో వెబ్ డెవలపర్ వివేచన ఆధారంగా "స్థానిక సమాన అంశాల"ను ఉపయోగించవచ్చు. స్థితి సంకేతం ఒక సమస్యను సూచిస్తున్నట్లయితే, వినియోగదారు ఏజెంట్ సమస్య యొక్క మరింత సమాచారాన్ని వినియోగదారుకు అందించడానికి హేతుబద్ధ అంశాన్ని ప్రదర్శించవచ్చు. ఈ ప్రమాణం వినియోగదారు ఏజెంట్ హేతుబద్ధ అంశాన్ని అనువదించడానికి చేసే ప్రయత్నాన్ని కూడా అనుమతిస్తుంది, అయితే దీనిని అవివేకంగా చెప్పవచ్చు ఎందుకంటే ఈ ప్రమాణంలో స్థితి సంకేతాలను యంత్రం అర్థం చేసుకునేందుకు మరియు హేతుబద్ధ విషయాల ను మానవులు అర్థం చేసుకోవడానికి ఉద్దేశించినట్లు పేర్కొంటుంది.

నిరంతర అనుసంధానాలు[మార్చు]

HTTP/0.9 మరియు 1.0ల్లో, ఒక అభ్యర్థన/ప్రతిస్పందన యుగ్మం తర్వాత అనుసంధానం మూసివేయబడుతుంది. HTTP/1.1లో ఒక నిరంతర యాంత్రికచర్య ప్రవేశపెట్టబడింది, దీనిలో ఒకటి కంటే ఎక్కువ అభ్యర్థనల కోసం ఒక అనుసంధానాన్ని మళ్లీ ఉపయోగించవచ్చు.

ఇటువంటి నిరంతర అనుసంధానాలు ఆలస్య అనుభూతిని తగ్గిస్తాయి, ఎందుకంటే క్లయింట్ మొట్టమొదటి అభ్యర్థనను పంపిన తర్వాత మళ్లీ TCP అనుసంధానాన్ని నిర్వహించవల్సిన అవసరం లేదు.

ప్రోటోకాల్ యొక్క 1.1 సంస్కరణ HTTP/1.0కు బ్యాండ్‌విడ్త్ ఆప్టిమైజేన్ మెరుగుదలలను అందించింది. ఉదాహరణకు, HTTP/1.1 నిరంతర అనుసంధానాలపై విషయాన్ని బఫర్‌లో ఉంచకుండా ప్రసారం అయ్యేందుకు అనుమతించే భాగాల బదిలీ ఎన్‌కోడింగ్‌ను ప్రవేశపెట్టింది. HTTP పైప్‌లైనింగ్ ఆలస్య సమయాన్ని మరింత తగ్గించింది, ఇది మొట్టమొదటి అభ్యర్థనకు ప్రతిస్పందనను పొందడానికి ముందే పలు అభ్యర్థనలను పంపడానికి క్లయింట్‌ను అనుమతిస్తుంది. ప్రోటోకాల్‌లో మరొక సౌలభ్యం ఏమిటంటే బైట్ సమాచారం మాత్రమే పంపడం, అంటే ఒక సర్వర్ వనరులో ప్రత్యేకంగా క్లయింట్ అభ్యర్థించిన భాగాన్ని మాత్రమే ప్రసారం చేస్తుంది.

HTTP సెషన్ స్థితి[మార్చు]

HTTP అనేది స్వతంత్ర ప్రోటోకాల్. ఒక స్వతంత్ర ప్రోటోకాల్‌లో సర్వర్ పలు అభ్యర్థనల వ్యవధిలో ప్రతి వినియోగదారు గురించి సమాచారం లేదా స్థితిని నిల్వ చేయవల్సిన అవసరం లేదు. ఉదాహరణకు, ఒక వెబ్ సర్వర్ ఒక వినియోగదారు కోసం ఒక వెబ్ పుటలోని అంశాన్ని అనుకూలీకరించవలసినప్పుడు, వెబ్ అనువర్తనం వినియోగదారు యొక్క ప్రగతిని పుటలవారీగా నిల్వ చేయవల్సిన అవసరం ఉండవచ్చు. ఒక సాధారణ పరిష్కారం HTTP కుకీలను ఉపయోగించాలి. ఇతర పద్ధతుల్లో సర్వర్‌లో నిర్వహించబడే సెషన్లు, అదృశ్య కారకాలు (ప్రస్తుత పుట ఒక ఫారమ్ అయినప్పుడు) మరియు URL ఎన్‌కోడెడ్ పరిమితులను ఉపయోగించినప్పుడు URL మళ్లీ రాయడం మొదలైనవి ఉన్నాయి, ఉదా. /index.php?session_id=some_unique_session_code.

సురక్షిత HTTP[మార్చు]

ఒక సురక్షితమైన HTTP అనుసంధానాన్ని ఏర్పాటు చేయడానికి ప్రస్తుతం రెండు పద్ధతులు అందుబాటులో ఉన్నాయి: https URI స్కీమ్ మరియు RFC 2817 పరిచయం చేసిన HTTP 1.1 అప్‌గ్రేడ్ శీర్షిక. అయితే అప్‌గ్రేడ్ శీర్షికకు బ్రౌజర్ మద్దతు దాదాపు లేదు, కనుక HTTPS ఇప్పటికీ ఒక సురక్షితమైన HTTP అనుసంధానాన్ని ఏర్పాటు చేయడానికి ప్రధాన పద్ధతిగా పేర్కొనబడుతుంది. సురక్షితమైన HTTP వెబ్ URIల్లో http://null బదులుగా ప్రారంభంలో https:// ఉంటుంది.

https URI స్కీమ్[మార్చు]

https అనేది ఒక URI పథకం, ఇది స్కీమ్ టోకెన్ మాత్రమే కాకుండా, సూత్రపరంగా సాధారణ HTTP అనుసంధానాలకు ఉపయోగించే httpకు సమానంగా ఉంటుంది, కాని ఇది ట్రాఫిక్‌ను సంరక్షించడానికి బ్రౌజర్ SSL/TLS యొక్క ఒక అదనపు గుప్తలేఖన లేయర్‌ను ఉపయోగించేలా చేస్తుంది. SSL అనేది ప్రత్యేకంగా HTTPకు మాత్రమే అనుకూలంగా ఉంటుంది ఎందుకంటే ఇది సంభాషణలో ఒకవైపు మాత్రమే ప్రమాణీకృతమైనప్పటికీ కొంతస్థాయిలో సంరక్షణను అందిస్తుంది. ఈ విధంగా ఇంటర్నెట్‌లో HTTP లావాదేవీలతో సంభవిస్తుంది, దీనిలో సాధారణంగా సర్వర్ మాత్రమే ప్రమాణీకృతంగా చెప్పవచ్చు (క్లయింట్ సర్వర్ యొక్క ధ్రువపత్రాన్ని పరిశీలించడం ద్వారా).

HTTP 1.1 అప్‌గ్రేడ్ శీర్షిక క్షేత్రం[మార్చు]

HTTP 1.1 అప్‌గ్రేడ్ శీర్షిక క్షేత్రానికి మద్దతు అందించింది. దీనికి మారుగా, క్లయింట్ ఒక స్పష్టమైన పాఠ్య అభ్యర్థనలను పంపడం ప్రారంభించింది, ఇది తర్వాత ట్రాన్సపోర్ట్ లేయర్ సెక్యూరిటీ (TLS)గా నవీకరించబడింది. క్లయింట్ లేదా సర్వర్ అనుసంధానం నవీకరించబడాలని అభ్యర్థించవచ్చు. అనుసంధానాన్ని నవీకరించాలని ఒక సర్వర్ ఆదేశం అనంతరం క్లయింట్‌చే ఒక స్పష్టమైన పాఠ్య అభ్యర్థనను సాధారణ పద్ధతిగా చెబుతారు.

క్లయింట్

GET /encrypted-area HTTP/1.1
Host: www.example.com

సర్వర్‌లు

HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade

సర్వర్ ఒక 426 స్థితి సంకేతాన్ని పంపుతుంది ఎందుకంటే 400 స్థాయి సంకేతాలు ఒక క్లయింట్ వైఫల్యాన్ని సూచిస్తాయి (HTTP స్థాయి సంకేతాల జాబితాను చూడండి), ఇది ఖచ్చితంగా ఆ వైఫల్యం క్లయింట్‌కు సంబంధించినదని ఉత్తరదాయిత్వ క్లయింట్‌లను హెచ్చరిస్తుంది.

ఒక సురక్షితమైన అనుసంధానాన్ని ఏర్పాటు చేయడానికి ఈ పద్ధతిని ఉపయోగించడం వలన ప్రయోజనాలు కింద ఇవ్వబడ్డాయి:

  • ఇది అస్పష్టమైన మరియు సమస్యాత్మక దిశ మళ్లింపులను మరియు సర్వర్‌లో URL మళ్లీ నమోదు కావడాన్ని తొలగిస్తుంది,
  • ఇది సురక్షిత వెబ్‌సైట్‌ల వర్చువల్ హోస్టింగ్‌ను అనుమతిస్తుంది (అయితే, HTTPS కూడా దీనిని సర్వర్ పేరు సూచనను ఉపయోగించి అనుమతిస్తుంది) మరియు
  • ఇది ఒక నిర్దిష్ట వనరును ప్రాప్తి చేయడానికి ఏకైక మార్గాన్ని అందించడం ద్వారా వినియోగదారు అస్పష్టతను తగ్గిస్తుంది.

ఈ పద్ధతిలో ఒక నష్టం ఏమిటంటే సురక్షిత HTTPకు అవసరమైన వాటిని URIలో సూచించడం సాధ్యం కాదు. ఆచరణలో, దీని వలన (నమ్మకమైన) క్లయింట్‌చే కాకుండా, (అవిశ్వాస) సర్వర్ సురక్షిత HTTPని ఏర్పాటు చేసే బాధ్యతను కలిగి ఉంటుంది.

ఉదాహరణ సెషన్[మార్చు]

ఒక HTTP క్లయింట్ మరియు www.example.com, పోర్ట్ 80లో ఒక HTTP సర్వర్‌ల మధ్య ఒక సాధారణ సంభాషణను కింద చూడండి.

క్లయింట్ అభ్యర్థన[మార్చు]

 GET /index.html HTTP/1.1
 Host: www.example.com

ఒక క్లయింట్ అభ్యర్థన (ఈ సందర్భంలో అభ్యర్థన పంక్తి మరియు ఒకే ఒక శీర్షికను మాత్రమే కలిగి ఉందనుకోండి) అనేది ఒక ఖాళీ పంక్తి తర్వాత పేర్కొనబడుతుంది, కనుక ఆ అభ్యర్థన ఒక ద్వంద్వ న్యూలైన్‌తో ముగుస్తుంది, ప్రతి ఒక్కటి ఒక లైన్ ఫీడ్ తర్వాత, ఒక క్యారేజీ రిటర్న్‌తో కోడ్ చేయబడుతుంది. "హోస్ట్" శీర్షిక ఒకే ఒక IP చిరునామాను పంచుకుంటున్న పలు DNS పేర్లను వేరు చేస్తుంది, ఇది పేరు ఆధారిత వర్చువల్ హోస్టింగ్‌ను అందిస్తుంది. ఇది HTTP/1.0 వైకల్పికమైనప్పటికీ, దీనిని HTTP/1.1 తప్పనసరిగా ఉపయోగించాలి.

సర్వర్ ప్రతిస్పందన[మార్చు]

 HTTP/1.1 200 OK
 Date: Mon, 23 May 2005 22:38:34 GMT
 Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
 Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
 Etag: "3f80f-1b6-3e1cb03b"
 Accept-Ranges: bytes
 Content-Length: 438
 Connection: close
 Content-Type: text/html; charset=UTF-8

ఒక ఖాళీ పంక్తి మరియు అభ్యర్థించబడిన పుటలోని పాఠం తర్వాత ఒక సర్వర్ ప్రతిస్పందన ఉంటుంది. ETag (ఎంటిటీ ట్యాగ్) శీర్షికను అభ్యర్థించిన వనరు యొక్క క్యాషీలోని సంస్కరణ, సర్వర్‌లోని ప్రస్తుత సంస్కరణతో సమానంగా ఉందో, లేదో గుర్తించడానికి ఉపయోగిస్తారు. Content-Type అనేది http సందేశంలోని సమాచారం యొక్క ఇంటర్నెట్ యానక రకాన్ని సూచిస్తుంది, Content-Length అనేది బైట్‌ల్లో దాని పొడవును తెలియజేస్తుంది. HTTP/1.1 వెబ్‌సర్వర్ శీర్షిక Accept-Ranges: bytes ను ఉంచడం ద్వారా పత్రంలోని నిర్దిష్ట బైట్ పర్యంతం అభ్యర్థనలకు ప్రతిస్పందించే దాని సామర్థ్యాన్ని పేర్కొంటుంది. క్లయింట్‌కు సర్వర్‌లోని ఒక వనరు యొక్క నిర్దిష్ట భాగాలు[17] మాత్రమే అవసరమైన సందర్భంలో ఇది ఉపయోగకరంగా ఉంటుంది, దీనిని బైట్ సర్వెంగ్ అంటారు. ఒక శీర్షికలో Connection: close ను పంపినప్పుడు, దీని అర్థం ఈ ప్రతిస్పందనను బదిలీ చేసిన వెంటనే వెబ్ సర్వర్ TCP అనుసంధానాన్ని మూసివేస్తుంది.

వీటిని కూడా చూడండి[మార్చు]

  • ప్రాథమిక ప్రాప్తి ప్రమాణీకరణ
  • విషయ మంతనాలు
  • కర్ల్-లోడెర్ - HTTP/S లోడింగ్/టెస్టింగ్ ఓపెన్-సోర్స్ SW
  • సారాంశ ప్రాప్తి ప్రమాణీకరణ
  • HTTP కంప్రెషన్
  • HTTP-MPLEX
  • HTTP(P2P)
  • Hxxp
  • ఫైల్ బదిలీ ప్రోటోకాల్‌ల జాబితా
  • HTTP శీర్షికల జాబితా
  • HTTP స్థితి సంకేతాల జాబితా
  • రిప్రెజెంటేషనల్ స్టేట్ ట్రాన్సఫర్ (REST)
  • SPDY - గూగుల్ ప్రతిపాదించిన ఒ HTTP ప్రత్యామ్నాయం.
  • వాకా (ప్రోటోకాల్) - రాయ్ ఫీల్డింగ్ ప్రతిపాదించిన ఒక HTTP ప్రత్యామ్నాయం.
  • వెబ్ క్యాషీ
  • WebDAV

సూచనలు[మార్చు]

  1. 1.0 1.1 1.2 Fielding, Roy T.; Gettys, James; Mogul, Jeffrey C.; Nielsen, Henrik Frystyk; Masinter, Larry; Leach, Paul J.; Berners-Lee (June 1999). "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1". 
  2. ఫీల్టింగ్, మొదలైనవారు. ఇంటర్నెట్ RFC 2616.", విభాగం 1.4. 21 జనవరి 2009 పునరుద్ధరించబడింది.
  3. Berners-Lee, Tim. "HyperText Transfer Protocol". World Wide Web Consortium. Retrieved 31 August 2010.  More than one of |author= and |last= specified (help)
  4. Tim Berners-Lee. "The Original HTTP as defined in 1991". World Wide Web Consortium. Retrieved 24 July 2010. 
  5. Raggett, Dave. "Dave Raggett's Bio". World Wide Web Consortium. Retrieved 11 June 2010. 
  6. Raggett, Dave; Berners-Lee, Tim. "Hypertext Transfer Protocol Working Group". World Wide Web Consortium. Retrieved 29 September 2010. 
  7. Raggett, Dave. "HTTP WG Plans". World Wide Web Consortium. Retrieved 29 September 2010. 
  8. 8.0 8.1 8.2 Simon Spero. "Progress on HTTP-NG". World Wide Web Consortium. Retrieved 11 June 2010. 
  9. "HTTP/1.1". Webcom.com Glossary entry. Retrieved 2009-05-29. 
  10. Cailliau, Robert (1 July 1992). "Updates To HTTP". World Wide Web Consortium. Retrieved 1 September 2010. 
  11. "Apache Week. HTTP/1.1".  090502 apacheweek.com
  12. Jacobs, Ian (2004). "URIs, Addressability, and the use of HTTP GET and POST". Technical Architecture Group finding. W3C. Retrieved 26 September 2010. 
  13. "Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections". US-CERT. 2002-05-17. Retrieved 2007-05-10. 
  14. Dusseault, Lisa; Snell, James M. "RFC 5789: PATCH Method for HTTP". 
  15. "HTTP 1.1 Section 5.1.1". Tools.ietf.org. Retrieved 2010-08-01. 
  16. "6.1 Status-Line". W3.org. Retrieved 2010-08-01. 
  17. Tools.ietf.org, బైట్ రేంజ్ రిట్రీవల్ ఎక్స్‌టెన్షన్ టు HTTP

మరింత చదవడానికి[మార్చు]

బాహ్య లింకులు[మార్చు]

Commons-logo.svg
వికీమీడియా కామన్స్‌లో కి సంబంధించిన మీడియా ఉంది.
  • "Change History for HTTP". W3.org. Retrieved 2010-08-01.  ఏ డిటైలెడ్ టెక్నికల్ హిస్టరీ ఆఫ్ HTTP.
  • "Design Issues for HTTP". W3.org. Retrieved 2010-08-01.  డిజైన్ ఇష్యూస్ బై బెర్నెర్స్-లీ వెన్ హీ వజ్ డిజైనింగ్ ది ప్రోటోకాల్.
  • "Classic HTTP Documents". W3.org. 1998-05-14. Retrieved 2010-08-01.  లిస్ట్ ఆఫ్ అదర్ క్లాసిక్ డాక్యుమెంట్స్ రికౌంటింగ్ ది ఎర్లీ ప్రోటోకాల్ హిస్టరీ

మూస:Semantic Web మూస:URI scheme