ugrás a tartalomhoz

Jön a HTTP/2.0

Hidvégi Gábor · 2012. Jan. 25. (Sze), 18.35
A W3C-nél 13 év után elérkezettnek látták az időt a váltásra
 ■
1

És én továbbra is várom a

H.Z. v2 · 2012. Jan. 25. (Sze), 19.39
És én továbbra is várom a megfejtést arra a kitételre, miszerint NAT esetén is működőképes lesz. (miért ne lenne, miért kellett kihangsúlyozni?)
3

Szerintem Poetro jót írt a

Hidvégi Gábor · 2012. Jan. 25. (Sze), 22.02
Szerintem Poetro jót írt a fórumtémában adott válaszában; magam laikusként úgy vélem, hogy a NAT-nak nem kéne köze legyen ehhez a protokollhoz. Esetleg másik NAT-ra gondoltak, a számítástechnikában szokás mindennek mágikus nevet adni, aztán meg betűzni.
2

HTTP 1.1

Poetro · 2012. Jan. 25. (Sze), 20.13
Én pedig azt várom, hogy a HTTP 1.1-et mikor fogja támogatni minden webszerver és szerver oldali keretrendszer.
4

Az alkalmazásoknak kellene

Joó Ádám · 2012. Jan. 26. (Cs), 00.27
Az alkalmazásoknak kellene támogatniuk, nem a kiszolgálóknak. Ez persze nehéz úgy, ha tíz fejlesztőből kilenc nem tudja felsorolni, milyen metódusok léteznek.
5

Mindkettőtöknek igaza van. A

Hidvégi Gábor · 2012. Jan. 26. (Cs), 08.49
Mindkettőtöknek igaza van. A PHP pl. hivatalosan csak a GET-et és a POST-ot támogatja, a PUT, DELETE és társaik használata már körülményes. Legjobb tudomásom szerint ugyanez igaz a böngészőkre is.
6

A PHP csak egy dolog

Kaszás Balázs · 2012. Jan. 26. (Cs), 15.08
A Rails kezdetektől fogva úgy épül fel, hogy támogatja a PUT/DELETE és társait, ám csak magasabb szinten. Low-level pontosan ugyanolyan POST megy el, csak kap egy method paramétert. Miért? A világon sokszázezer proxy szerver van, amik még csak hírből sem hallottak ilyen metódusokat, vagy ha ismerik is, alapértelmezetten le vannak tiltva.

Ezen nem lehet csodálkozni, amikor a Google a cache-eléssel összefüggésben azt ajánlja, hogy még query stringet se használjunk a statikus tartalmaknál, mert azokat is általában rosszul kezelik a proxyk:
http://code.google.com/intl/hu/speed/page-speed/docs/caching.html#LeverageProxyCaching

A HTTP/2.0-ban nem a metódusok kibővítése a cél, hanem pl. a multiplexing vagy a header compression.

szerk: veletlenul beleszerkesztettem a hozzaszolasodba valasz helyett, ha minden igaz, akkor visszaallitottam az eredeti allapotot, ha megsem, akkor irj ram, mi hianyzik es javitom. bocsi. Tyrael voltam.
7

Én ezekkel a PUT/DELETE

Hidvégi Gábor · 2012. Jan. 26. (Cs), 15.48
Én ezekkel a PUT/DELETE metódusokkal úgy vagyok, hogy ha olyan hasznosak lennének, már megoldották volna, hogy használjuk.
A HTTP/2.0-ban nem a metódusok kibővítése a cél, hanem pl. a multiplexing vagy a header compression.
Hajrá! Hátha a HTTP első változatának huszadik évfordulójára elkészülnek vele. Bár úgy vagyok vele, hogy még mindig inkább ez, mint a google-féle marketingszagú SPDY.
9

Én ezekkel a PUT/DELETE

Tyrael · 2012. Jan. 27. (P), 21.41
Én ezekkel a PUT/DELETE metódusokkal úgy vagyok, hogy ha olyan hasznosak lennének, már megoldották volna, hogy használjuk.


REST webservice-eknel bevett szokas a hasznalatuk.
http://en.wikipedia.org/wiki/Representational_state_transfer

Tyrael
10

A Rails kezdetektől fogva úgy

Tyrael · 2012. Jan. 27. (P), 22.05
A Rails kezdetektől fogva úgy épül fel, hogy támogatja a PUT/DELETE és társait, ám csak magasabb szinten. Low-level pontosan ugyanolyan POST megy el, csak kap egy method paramétert. Miért? A világon sokszázezer proxy szerver van, amik még csak hírből sem hallottak ilyen metódusokat, vagy ha ismerik is, alapértelmezetten le vannak tiltva.


AFAIR siman tamogatja a rails is a kulonbozo metodusokat:
http://guides.rubyonrails.org/routing.html#resources-on-the-web

ha van valami linked errol, hogy a rails a metodusban beallitott method helyett POST-ot kuld, azt szivesen megneznem.

Ezen nem lehet csodálkozni, amikor a Google a cache-eléssel összefüggésben azt ajánlja, hogy még query stringet se használjunk a statikus tartalmaknál, mert azokat is általában rosszul kezelik a proxyk:

a rosszul kezelik valojaban annyit jelent, hogy van(volt) legalabb 1 olyan proxy, ahol a fejlesztok lustak volnak a cachebol torteno kiszolgalasnal megvizsgalni, hogy a query string is megegyezik-e az aktualisan lekert es a korabban mar lecachelt tartalom urljeben, ehelyett inkabb sosem cacheltek olyan tartalmat, amiben szerepel query string. (ez csak eroforraspazarlas, de semmilyen mas problemat nem okoz egyik felnek sem)

A HTTP/2.0-ban nem a metódusok kibővítése a cél, hanem pl. a multiplexing vagy a header compression.

HTTP Pipelining mar van az 1.1-ben is, csak nem tamogatja meg mindenki, a header compression erdekes otlet, bar szerintem tul nagy szemantikus valtoztatas lenne ahhoz, hogy bevezessek.

Tyrael
19

ha van valami linked errol,

Kaszás Balázs · 2012. Feb. 6. (H), 17.50
ha van valami linked errol, hogy a rails a metodusban beallitott method helyett POST-ot kuld, azt szivesen megneznem.


http://guides.rubyonrails.org/form_helpers.html#how-do-forms-with-put-or-delete-methods-work

Erre gondoltam.

a rosszul kezelik valojaban annyit jelent, hogy van(volt) legalabb 1 olyan proxy...


És ennyi pont elég ahhoz is, hogy ne lehessen world-wide használni a különlegesebb HTTP metódusokat.
20

koszi, most jovok ra, hogy a

Tyrael · 2012. Feb. 7. (K), 15.58
koszi, most jovok ra, hogy a form generalasra gondoltal.
igen, a browserek nem (nagyon) tamogatjak a GET/POST-on kivuli form kuldest, a html speci anno csak ezt definialta form methodnak.

html5-ben ha jol tudom eloszor be, majd kikerult a tobbi metodus tamogatasa, de ha jol emlekszem az XmlHttpRequest-en keresztul pl. lehetseges a bongeszobol is PUT/DELETE/etc. metodussal kerest kuldeni.

"És ennyi pont elég ahhoz is, hogy ne lehessen world-wide használni a különlegesebb HTTP metódusokat."
tehat abbol, hogy van olyan proxy, ami a kelletenel kevesbe hatekony modon cacheli a a get parameterrel rendelkezo statikus eroforrasokat, kovetkezik az, hogy a kevesbe elterjedt HTTP protokollokat nem lehet tamogatni?

ne erts felre, igazad van abban, hogy amig van (sok) olyan proxy ami nem implementalta a HTTP 1.0/1.1 spec idevago reszet, (es amig a major browserek szinten nem tamogatjak rendesen) addig nem tud terjedni kliens oldalon a tobbi metodus, de ezek ugyanazon problema kovetkezmenyei (emberi lustasag, a felhasznalonak nincs igenye a szemantikus webre, a proxy/browser fejlesztok nem torik magukat, a HTML spec nem rendelkezett errol), nem oka egyik a masiknak.

Tyrael

Tyrael
21

...a html speci anno csak ezt

Arnold Layne · 2012. Feb. 7. (K), 16.18
...a html speci anno csak ezt definialta form methodnak.

Úgy tudom volt valaha egy XForms nevű, amivel ment például a PUT is. Azóta nem hallottam semmit erről. :(
...de ha jol emlekszem az XmlHttpRequest-en keresztul pl. lehetseges a bongeszobol is PUT/DELETE/etc. metodussal kerest kuldeni.

Firefox-szal próbáltam anno (nem egész egy éve) és a KISCSIRKE is elment. Vagy valami hasonló kreatív nevű metódussal próbálkozhattam.
22

curl-lel tesztelgettem

Tyrael · 2012. Feb. 7. (K), 18.32
curl-lel tesztelgettem valamelyik nap, elfogadott ott is mindent methodusnak, es php-bol is ott volt a kiscsirke a $_SERVER['REQUEST_METHOD']-ban. :)

Tyrael
8

mit ertesz pontosan az alatt,

Tyrael · 2012. Jan. 27. (P), 21.39
mit ertesz pontosan az alatt, hogy csak a GET és a POST tamogatott?

PHP-bol a $_SERVER['REQUEST_METHOD'] -on keresztul elered az aktualis kereshez hasznalt metodust.

ha a $_GET/$_POST szuperglobalis tombok miatt gondolod, hogy mas nem tamogatott, az csak egy felreertes, a $_GET mindig csak az url-ben a query string-en atadott parametereket tartalmazza, mig POST keres eseteben a HTTP request torzseben szereplo kulcs/ertek parokat fogja a $_POST tomb tartalmazni.

a HEAD eseteben a php egyszeruen nem ad vissza a valaszban contentet, csak a fejleceket(kovetve a szabvanyt ezaltal).

a PUT-tal torteno egyszeru fajlfeltoltes-re egy pelda a manualbol: http://php.net/manual/en/features.file-upload.put-method.php

a DELETE/OPTIONS/etc. szinten implementalhato tetszes szerint.

Tyrael
11

A mondatom első felében nem

Hidvégi Gábor · 2012. Jan. 27. (P), 22.12
A mondatom első felében nem jól fogalmaztam, és valóban arra gondoltam, hogy a $_GET és $_POST szuperglobálok jelenléte miatt jobban támogatott ez a két metódus. Ha a többinek lenne értelme, használnák az átlag weboldalak is.
13

Használom

janoszen · 2012. Jan. 28. (Szo), 10.25
Én használom, teljesen jól müködik. Hol akadtál el vele?
14

Egy fecske nem csinál nyarat.

Hidvégi Gábor · 2012. Jan. 28. (Szo), 14.14
Milyen előnyökkel jár a fentebb sorolt kéréstípusok használata a GET-hez és a POST-hoz képest? Egy PUT-os fájlfeltöltés miben jobb a POST-osnál?
15

Itt szépen le van írva mi

MadBence · 2012. Jan. 28. (Szo), 14.34
Itt szépen le van írva mi mire való. (Technikailag semmi többet nem tud a PUT, hogy a kérdésre is válaszoljak)
Olyan ez, minthogy a div-ek helyett kitalálták a header-footer-stb tagokat.
16

Ezzel tisztában vagyok

Hidvégi Gábor · 2012. Jan. 28. (Szo), 14.51
Lásd 11-es hozzászólásom utolsó mondatát.
17

Ha a többinek lenne értelme,

kuka · 2012. Jan. 28. (Szo), 19.16
Ha a többinek lenne értelme, használnák az átlag weboldalak is.
Én úgy tudtam, hogy a PUT és a DELETE a FrontPage-féle ál-remote weblap szerkesztéshez lett használva. Azaz nem a böngészők számára lettek kitalálva, tehát a böngészők általi támogatásuk kérdése valószínűleg soha fel sem merült.
18

A webet kollaboratív,

Joó Ádám · 2012. Jan. 28. (Szo), 20.40
A webet kollaboratív, elosztott dokumentumkezelő rendszernek (helló wiki!) tervezték, melynek legalább annyira része a tartalmak létrehozása és szerkesztése, mint keresése és megtekintése. Tehát de, a böngészők számára lettek kitalálva, csak azok sosem valósították meg (leszámítva az egy Amayát).
12

LigHTTPd

janoszen · 2012. Jan. 28. (Szo), 10.22
A Lighty a mai napig nem támogatja az Expect: 100 Continue headert, ami miatt Operából nem megy normálisan a fájlfeltöltés.