ugrás a tartalomhoz

http 412

zzrek · 2011. Már. 2. (Sze), 22.39
Sziasztok!

Az egyik emberkénél előfordult, hogy a webes alkalmazásom 412-es hibát dobott.
Ezt találtam róla: E412

Jól értelmezem ezt, ezek szerint én nem nagyon tudok ilyesmivel mit kezdeni (php-js szinten)? Csak remélni tudom, hogy a tárhelyem legközelebb jól elérhető lesz és ez a hiba csak ritkán fog előjönni, ugye? (Mármint lekezelni, vizsgálni azt tudom, de nem tudom megelőzni, ugye?) Biztos, hogy én nem rontottam el semmit? (php-html-JS)

Köszönöm!
 
1

Expect

janoszen · 2011. Már. 2. (Sze), 23.03
A precondition failed hiba azt jelenti, hogy valamilyen követelmény, amit a requestben megfogalmaztál, nem teljesült. Ilyen lehet például az Accept header vagy hasonlók. (Vigyázat, az Expect header kapcsán felmerült hiányosságnak más hibakódja van!)

Ez lehet például azért, mert a böngészőjében el van tekerve valami. Ha rávehető, telepíttess vele valamilyen monitoring eszközt és dumpoltasd ki a HTTP requestet.
2

Sajnos teljesen normál user

zzrek · 2011. Már. 2. (Sze), 23.17
Sajnos teljesen normál user, nem tudok tőle semmit sem kérni.
Annyi kiderült, hogy safarija van (gondolom mac, még nem néztem utána jobban)
Javascripttel nemigen küldtem ki különleges accept headert a httpreq-vel, de megnézem.

(Sajnos még nem oldódott meg a gond, pedig azt hittem, hogy ez csak valamilyen ideiglenes kapcsolati hiba lesz -- "tegnap még működött és azóta nem csináltam semmit" jellegű a dolog)

Köszi a segítséget!
3

Meg kéne nézni, hogy milyen

inf · 2011. Már. 3. (Cs), 00.22
Meg kéne nézni, hogy milyen headereket küld meg kap... Nem tudom safarinak milyen kiterjesztései vannak az ilyesmihez, de csak lehet figyelni valahogyan az adatforgalmat, ha mást nem, akkor neked kéne loggolni a szerveren. Szerintem ki lehet deríteni, hogy pontosan mi a kínja.
4

Most jó lett

zzrek · 2011. Már. 3. (Cs), 00.46
Most jó lett egyelőre. Ez már csak ilyen... Legalább most közelebbi ismertségbe kerültem a 412-vel. Majd valahogy megpróbálom logolni, aztán majd ha rájöttem valami érdekesre, akkor majd ide postolom, vagy kérdezek még. Köszi a segítséget!
(Off: A szerver órája siet?)
6

Nyári időszámítás

Poetro · 2011. Már. 3. (Cs), 00.54
Azt hiszem nyári időszámításra van beállva :P
5

Dedikált program

Poetro · 2011. Már. 3. (Cs), 00.53
Windows alatt ugye a HTTP forgalmat lehet figyelni például Fiddler-rel, és a MacOS X alatt is futó Wireshark-kal. Ezen kívül alapból a Safari része (ahogy a Chrome-é is) a Web Inspector (Chrome alatt Developer Tools a neve), ami a Firebug Webkit-es megfelelője.
7

sajnos

zzrek · 2011. Május. 9. (H), 09.19
Sajnos még mindig fennáll néha a hiba. Most már biztos, hogy a Safari miatt történik a dolog.
Ezt az egy infót találtam a neten ezzel kapcsolatban, gyanítom, hogy az én esetemben is ez lehet:

http://www.freestyle-developments.co.uk/blog/?p=11

Kérlek, segítsetek értelmezni, miféle headert küld másképp a Safari?
Nem teljesen értem, hogy hogyan oldották meg ők ezt a problémát??
Hogyha az XMLHttpRequest-ben állítok valamit a setRequestHeader-rel, akkor az segíthet?

Köszönöm!
8

post->get

zzrek · 2011. Május. 9. (H), 09.59
Persze, azt értem hogy átálltak get-re, és ez náluk megoldotta dolgot...
Nem nagyon akarnék én is átállni, de ha más megoldás nincs, akkor esetleg ezt teszem (csak nem vagyok benne biztos, hogy esetleg ez okoz-e más gondot)
9

Hibakeresés lépései

vbence · 2011. Május. 9. (H), 11.31
Én feltennék egy Safarit, megnézném a hibalogokat Apache oldlaon, esetleg egy loggoló proxy szervert közbeiktatnék. 99% hogy ezekkel a lépsekkel kiderül a probléma.
10

próbáltam safarival

zzrek · 2011. Május. 9. (H), 13.03
Próbáltam safarival, de nekem nem jött elő (egyébként ott is ritka ahol előjön), lehet hogy azért, mert a Mac-es Safarin probléma ez (Mac-et pedig most nem veszek inkább, majd esetleg holnap ;-)
Az Apache hibaloghoz nem férek hozzá (shared host) és macerás lenne proxyt is közbeiktatni.
Tegyük fel, hogy ha ezeket megtenném, tényleg az derülne ki, amit a fenti linken írnak, vagyis:
Safari responds to etags properly and adds "If-None-Match" and
"If-Modified-Since" headers to another request for the same file. This makes
Apache respond with a 412 status (Precondition Failed) as it should do for
"post" requests (according to RFC 2616).


Ha jól értem, akkor csak abban az esetben van probléma, ha a fájlt (ami változatlan) másodszor is lekérem, ugye?

Valahogy nem lehetne elintézni, hogy a Safari ne küldje ki ezeket a headereket? Esetleg egy más, plusz headerrel kitrükközni az Apache válaszát?

Ez az "etag" ez micsoda tulajdonképp, ez egy Mootools izé, vagy valami köze van a HTTP-hez?

Ha esetleg átállnék POST-ról GET-re mire számíthatok? Gondolom UTF8-as karakterek nemigazán mennének át GET-tel, ugye?

Köszi a tippeket, tanácsokat!
11

Random URL és OS X

vbence · 2011. Május. 9. (H), 13.55
Első körben posztolhatsz minig más URL-re, egy GET paraméter segítségével pl:

http://example.com/alax.php?rnd=3284324632743

Proxyt a localhoston is könnydén közbeiktathatsz. Sokat segít a webfejlesztésben ha egy ilyen cucc is az eszköztárad része.

Mac OS X-et pedig virtuális gépre is tudsz telepíteni... osx86project.org
12

hmmm

zzrek · 2011. Május. 9. (H), 16.17
Első körben posztolhatsz minig más URL-re, egy GET paraméter segítségével...


De ez azt jelentené, hogy mindig lekéri, és sose gyorstáraz, stb, nem?
Nekem az nem baj, ha mondjuk 304 jön vissza, csak legyen benne a responseText-ben a cucc.
Lehet, hogy azt fogom csinálni, hogy eltárolom a localStorage-ben, aztán ha 412 jön, akkor tudni fogom, hogy nem változott semmi.

Vagy valamit félreértettem?
16

304 és responseText

vbence · 2011. Május. 9. (H), 20.23
Nekem az nem baj, ha mondjuk 304 jön vissza, csak legyen benne a responseText-ben a cucc


Akkor mi a különbség? A 304 lényege az lenne, hogy nincs változás, tehát nincs response body (nincs xhr.responseText).
The 304 response MUST NOT contain a message-body


Mellesleg POST esetén nincs 304 sem.
17

nem tudom

zzrek · 2011. Május. 9. (H), 21.16
Nem tudom, biztosan igazad van, végülis 304-gyel még nem volt gondom, csak azt hittem hogy 304 esetében (mivel a "nem volt változás" jelzésnek ekkor van értelme) a böngésző a tartalmat a gyorstárból szolgáltatja (képek esetében legalábbis tuti hogy ezt teszi).
De teljesen mindegy, csak azt akartam érzékeltetni, hogy szeretném jól értelmezni a dolgot, és ha tényleg úgy van, hogy akkor van a probléma ha második betöltésnél változatlan a dolog, akkor végülis ezt le tudom kezelni.

Nem annyira sürgős a dolog, van időm próbálgatni, csak jó volt megkérdezni itt a fórumon, hogy kinek mi az ötlete, mivel próbálkozzak, van-e ilyen tapasztalat, szóval köszi a hozzászólásokat!
13

random helyett inkább filectime

solkprog · 2011. Május. 9. (H), 16.36
Random helyett inkább szerintem jobb lekérni manuálisan a fájl utolsó módosítását, és azt hozzácsapni az URL végére. (És így a böngésző cache-t nem csapjuk agyon, de módosítások azonnal eljutnak a felhasználókhoz.)
14

igen

zzrek · 2011. Május. 9. (H), 17.39
Igen, de ha jól értettem, akkor valószínűleg abból ered a probléma, hogy ha másodszor kérem le ugyanazt (post metódussal) akkor a Safari olyan headert küld, amitől az Apache 412 hibát küld vissza.
15

igaz

solkprog · 2011. Május. 9. (H), 18.56
igaz..
de akkor tényleg tegyél fel egy OSX-et virtual gépen és teszteld le, vagy írd ide kérdéses url-címet, csak van valakinek itt OSX-e..

speciel engem az is érdekelne hogy te milyen header-ökkel válaszolsz.
Tipp: nem lehet hogy első kérésnél kiküldesz valami hibás fejlécet (Cache-Control, Expires, Etag) ami a Safari lelkivilágában zavartságot okozol a második kérésnél?
18

nem küldök semmit

zzrek · 2011. Május. 9. (H), 21.30
(Egy Facebook-os alkalmazásról van szó, szóval nem olyan egyszerű kipróbálni hogy "katt a linkre", ráadásul ez az első ilyenem, és nem vagyok rá büszke szakmailag, ezért nem akarom beposztolni ide a linkjét. A második alkalmazásom már jobb lesz, sokat tanultam belőle.)

Nem küldök semmi extra fejlécet, az XMLHttpRequest-el plusz header beállítás nélkül kiküldöm a kérést, az Apache meg azzal válaszol, amit a shared host szolgáltató beállított, nem piszkáltam bele.
19

Hiba

janoszen · 2011. Május. 10. (K), 19.44
Egy hasonló hiba nálam akkor fordult elő, amikor a kliens (nálam a curl) küldött Expect headert, azonban a LigHTTPd nem tudta kiszolgálni. A curlt külön le kellett beszélni arról, hogy ilyet tegyen. Ez 417-es (Expectation failed) hibát dobott, de hátha nálad is valami hasonló lesz. Én mindenképpen rátámadnék egy Wiresharkkal.