ПОСТ (ХТТП)
У рачунарству, ПОСТ је једна од многих метода за захтеве које подржава ХТТП протокол који се користи од стране светске мреже. ПОСТ метод је дизајниран да захтева да се са веб сервера прихвата податак послат у оквиру ХТТП захтева.[1] То се често користи када се шаље датотека или доставља попуњен веб формулар.
Насупрот томе, ХТТП ГЕТ метод је дизајниран да преузме податке са сервера. Као део ГЕТ метода, неки подаци могу бити донети у оквиру стринг упита УРИ-а, наводећи на пример термин за претрагу, датуме или друге информације које дефинише упит. Као део ПОСТ захтева, произвољна количина података било ког типа може бити послат на сервер у оквиру ХТТП захтева. ХТТП заглавље обично указује на формат ХТТП захтева.
Слање података[уреди | уреди извор]
Светска мрежа и ХТТП су засновани на бројним захтевним методима, укључујући ПОСТ и ГЕТ, као и ПУТ, ДЕЛЕТЕ, и још неколико других. Веб претраживачи обично користе само ГЕТ и ПОСТ, али остале онлајн апликације користе многе друге. ПОСТ-ов задатак у оквиру ХТТП метода јесте да пошаље представљање нове објектне везе са сервера, тако да се чува као нови завистан извор препознатљив по УРИ.[1] На пример, за УРИ http://example.com/customers, од ПОСТ захтева може се очекивати да представљају нове купце, укључујући њихова имена, адресе, контакт податке и тако даље. Рани веб дизајнери залутали су далеко од овог првобитног концепта на два начина. Прво, не постоји технички разлог да УРИ укратко опише завистан веб ресурс на који ће ПОСТ подаци бити сачувани. У ствари, уколико није утрошен неки напор, последњи део УРИ ће вероватно описати обраду Веб апликације на тој страни, као што су http://example.com/applicationform.php. Друго, с обзиром на ограничење веб претраживача да могу да користе само ГЕТ или ПОСТ, дизајнери су осетили потребу да поново намене ПОСТ метод да уради многе друге доставе података и задатака за управљање подацима, укључујући и промену постојећих евиденција и њихово брисање.
Напори неких утицајних писаца да исправи прву тачку почела је још 1998.[2] Оквирске веб апликације као што су Рубy он Раилс и друге олакшавају дизајнерима да обезбеде својим корисницима чисте УРЛ адресе. Што се тиче другог питања, могуће је користити клијентске скрипте, или написати самосталне апликације, које могу да користе друге методе ХТТПа где су релевантне,[3] али ван овога већина веб образаца који се шаљу или обавештавају сервер са подацима настављају да користе ПОСТ метод.
То не значи да свака веб форма треба да има наведен метход као "post" у свом почетном тагу. Многе форме се користе за прецизније преузимање информација са сервера, без икакве намере да се мења главна база података. Такви облици претраге су идеални да имају методу постављену на "get".[4]
Постоје тренуци када је ХТТП ГЕТ метод мање погодан за преузимање података. Пример за то је када би велики део података требало да буде наведен у УРЛ. Прегледачи и веб сервери могу да имају ограничења по питању дужине УРЛ који ће се читати без скраћивања или пријављивања грешке. Шифровање резервисаних знакова у УРЛ адресама и упитима може значајно да повећа њихову дужину, док Апач ХТТП сервер може да обради до 4.000 знакова у УРЛ-у,[5] Мајкрософтов Интернет екплорер је ограничен на 2048 знакова.[6] Исто тако, ХТТП ГЕТ не треба да се користи где су осетљиве информације, као што су корисничка имена и лозинке и они морају да се поднесу заједно са другим подацима из захтева. Чак и ако се користи ХТТПС, спречавајући да се подаци пресретну у транзиту, историја прегледача и логови веб сервера ће вероватно садржати пуну УРЛ адресу у отвореном тексту, који може бити изложен уколико је било који систем хакован. У овим случајевима, ХТТП ПОСТ треба користити.[7]
Начин слања веб образаца[уреди | уреди извор]
Када веб претраживач пошаље ПОСТ захтев из елемента веб формулар, подразумевани интернет медија тип је "апплицатион/x-www-форм-урленцодед".[8] Ово је формат за кодирање кључ - вредност паровима са могућим дуплим кључевима. Сваки кључ - вредност пар је одвојен '&' карактером, а сваки кључ је одвојен од своје вредности са '=' карактером. У кључевима и вредностима размаке можемо заменити знаком "+", а за остале за остале не-алфанумеричке[9] карактере можемо кодирати користећи УРЛ кодирање.
На пример, кључ - вредност парови
Ime: Ivan Jelić Godine: 23 Formula: A + B == 13% !
се кодирају као:
Ime=Ivan+Jelic&Godine=23&Formula=A+%2B+B+%3D%3D+13%25+%21
Почевши са ХТМЛ 4.0, форме могу да доставе податке у мултипарт/форм-дата као што је дефинисано у RFC 2388 (Види и RFC 1867 за експерименталну верзију раније дефинисану као проширење ХТМЛ 2.0 и поменути у ХТМЛ 3.2 ) .
Уколико је ПОСТ захтев већ послат клијентски програми обично упозоравају корисника да је ПОСТ захтев вец послат и то упозорење је познато као постбацк.
Референце[уреди | уреди извор]
- ^ а б „Хyпертеxт Трансфер Протоцол -- ХТТП/1.1”. RFC 2616. Приступљено 30. 5. 2013. „The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.” Спољашња веза у
|work=(помоћ) - ^ Berners-Lee, Tim (1998). „Cool URIs don't change”. W3C. Приступљено 30. 5. 2013.
- ^ Friedman, Mike (2009). „Using HTTP PUT and DELETE methods in web applications”. Приступљено 30. 5. 2013.
- ^ „Form submission”. HTML 4.01 Specification. W3C. 1999. Приступљено 30. 5. 2013.
- ^ Rigsby, Dan (2008). "REST and Max URL Size[мртва веза]". Приступљено 30. мај 2013.
- ^ „Maximum URL length is 2,083 characters in Internet Explorer”. Microsoft.
- ^ „Hypertext Transfer Protocol -- HTTP/1.1”. RFC 2616. Приступљено 30. 5. 2012. Спољашња веза у
|wорк=(помоћ) - ^ Бернерс-Лее, Тим; Цонноллy, Дан (22. 9. 1995). „Хyпертеxт Маркуп Лангуаге - 2.0 - Формс”. Wорлд Wиде Wеб Цонсортиум. Приступљено 30. 5. 2013.
- ^ „Формс ин ХТМЛ доцументс”.