[PHP/Apache] HTTP-reply conditioneel voorkomen

[Verwijderd]

Ik wil als er bepaalde condities optreden geen http-reply sturen.

Dus als een bepaalde php pagina wordt opgevraagd, deze request wel verwerken (bijvoorbeeld database wijzigingen) maar geen antwoord sturen. Momenteel genereer ik geen output, maar er wordt er natuurlijk wel een header teruggestuurt.

Iemand enig idee hoe ik dit voor elkaar kan krijgen?

[ACM]

Volgens mij wordt elke request beantwoord met een reply... (spec-technisch zelfs, meen ik)

Waarom zou je dat niet willen?

[Verwijderd]

De client die deze specifieke http-request doet is geen browser en verwacht (meestal) geen antwoord.

De reden waarom ik dit wil is het enigzins beperken van bandbreedte. Het duizenden keren van een header neemt toch wel wat bandbreedte in.

Ondanks de specs moet het toch mogelijk zijn om een request af te breken vlak voordat er een antwoord wordt gestuurd.

[ACM]

Je zou een eigen daemon kunnen maken die gewoon de connection afsluit/geen header stuurt na zo'n request? Heel moeilijk lijkt het me niet om een php of perl daemon voor zoiets te bakken, maar hoe het in apache moet weet ik iig niet. Het kan vast

[ Voor 4% gewijzigd door ACM op 16-06-2003 11:49 ]

[curry684]

HTTP stuurt inderdaad by-convention altijd een antwoord, een goed geimplementeerde browser zal anders namelijk minstens 5 retries eroverheen gooien. Absoluut not done dus.

Geef gewoon een dummy 404 terug die door de betreffende client getrunced wordt?

[Verwijderd]

Het moet helaas toch echt in apache gebeuren, aangezien er ook nog een hoop normale http requests op deze poort plaatsvinden (client kan niet meer worden aangepast)...

[DiedX]

Het enige wat ik bedenk is een losse header terugsturen? Zit je nog steeds met verkeer, maar ik denk dat je dat niet tegen kan houden.

[ACM]

Dan zit je waarschijnlijk aan je header vast, als je niet anders dan apache kan nemen en ook je client niet meer kan veranderen...

[Verwijderd]

Zou ik niet op een of andere manier kunnen faken dat de client de tcp connectie heeft verbroken? (in dat geval zal apache neem ik aan niet meer proberen een response te sturen)

[sebas]

Firewall de uitgaande connecties laten blokken is geen optie?

[curry684]

Verwijderd schreef op 16 June 2003 @ 11:47:
De client die deze specifieke http-request doet is geen browser en verwacht (meestal) geen antwoord.

Okee laat ik het kort samenvatten: een client die een HTTP-request doet zonder antwoord te verwachten voldoet niet aan de relevante RFC's en is dus onbruikbaar. Oftewel fix die client of bouw een nieuwe.

Je kunt wel de grootst mogelijke moeite doen om de webservers van deze wereld de HTTP-specificaties te laten negeren maar uiteindelijk is het toch je client die het verneukt. En zoals het altijd geldt in client/server programming land: de server heeft altijd gelijk!!!

* curry684 wordt het geneuzel hier een beetje zat

[Verwijderd]

curry684 schreef op 17 June 2003 @ 00:33:
Okee laat ik het kort samenvatten: een client die een HTTP-request doet zonder antwoord te verwachten voldoet niet aan de relevante RFC's en is dus onbruikbaar. Oftewel fix die client of bouw een nieuwe.

De client 'fixen' kan niet meer omdat er al duizenden in gebruik zijn (die nog geen autoupdate hadden, de laatste paar versies hebben dit wel). En waarom is het niet toegestaan om de werking van de server te veranderen, we zijn toch niet voor niets tweakers...

De client voldoet trouwens wel aan de http specs, alleen heeft hij dat antwoord soms helemaal niet nodig. En aangezien dit soort requests nogal vaak plaatsvinden wil ik dit voorkomen (om bandbreedte te sparen)

[ Voor 20% gewijzigd door Verwijderd op 17-06-2003 18:34 ]

[Hmmbob]

is het de moeite wel waard? Een header, dat is maar een paar bits (gok ik), en al heb je er 1024, dan zit je nog maar aan een kb... het lijkt me ook stug dat alle 10.000 clients tegelijkertijd een request doen, dus je evt 10 kb kwijt zou zijn.
Dat trekt je kabelverbindingkje ook nog wel

* Hmmbob ziet het probleem niet zo...

[Verwijderd]

Groentenboer schreef op 17 June 2003 @ 18:46:
is het de moeite wel waard? Een header, dat is maar een paar bits (gok ik), en al heb je er 1024, dan zit je nog maar aan een kb... het lijkt me ook stug dat alle 10.000 clients tegelijkertijd een request doen, dus je evt 10 kb kwijt zou zijn.
Dat trekt je kabelverbindingkje ook nog wel

/me ziet het probleem niet zo...

Het zijn momenteel zo'n 180.000 requests per dag, en de headers nemen toch wel een paarhonderd bytes in. Het zijn geen waanzinnige hoeveelheden data, maar toch wil ik het graag voorkomen.

[Soultaker]

Je kunt je response beperken tot een regel met "200 OK" erop (en twee newlines), dus dat zal in de praktijk niet meer dan één extra packet kosten. Ik kan me absoluut niet voorstellen dat dat je netwerk teveel belast. Is dat wel het geval, gebruik dan gewoon geen webserver maar een ander RPC-mechanisme (op basis van UDP, als je geen garanties hoeft te hebben, dat scheelt weer een hoop handshaking overhead).

[Spider.007]

Verwijderd schreef op 17 juni 2003 @ 19:09:
[...]


Het zijn momenteel zo'n 180.000 requests per dag, en de headers nemen toch wel een paarhonderd bytes in. Het zijn geen waanzinnige hoeveelheden data, maar toch wil ik het graag voorkomen.

Ik denk dat in dat geval de kosten niet opwegen tegen de baten...... Je wil breken met standaarden om een paar honderd bytes per dag te voorkomen

[coubertin119]

180.000 * 300 bytes (als voorbeeld) = 54000000 bytes, wat +/- 50 megabyte is per dag. Is het de moeite om het hiervoor te doen?

[Limhes]

Verwijderd schreef op 16 June 2003 @ 12:12:
Het moet helaas toch echt in apache gebeuren, aangezien er ook nog een hoop normale http requests op deze poort plaatsvinden (client kan niet meer worden aangepast)...

Dan kun je toch nog steeds je eigen daemon maken, apache op een andere poort gooien, je eigen daemon op de oude apache poort gooien en vervolgens de goeie http requests doorsturen naar de nieuwe apache poort, en de foute (die je wil afvangen) negeren.

[tomato]

Kom op, wil je de HTTP standaard maar voor de helft gebruiken, gebruik dan alsjeblieft gewoon geen HTTP. Ik kan me ten eerste niet voorstellen dat die 50 MB je iets uit maken, maar als dat echt zo is gebruik dan gewoon een ander protocol.

Het is niet zo gek dat dit niet makkelijk met Apache lukt, het is niet voor niets een HTTP webserver...

[Limhes]

En om de HTTP-puristen onder ons tevreden te houden kun je alsnog mijn idee gebruiken en een '200 OK' header terugsturen (zoals SoulTaker al suggereerde). Dat is nl. maar een paar bytes en geldige HTTP.

[curry684]

Soultaker schreef op 17 juni 2003 @ 19:26:
Je kunt je response beperken tot een regel met "200 OK" erop (en twee newlines), dus dat zal in de praktijk niet meer dan één extra packet kosten.

Als je zeker wil weten dat de URL genegeerd wordt kun je beter "404 Not Found" sturen. 13 bytes ipv 6, dus nog steeds 1 packet

offtopic:
Limhes dat was mijn idee trouwens: [rml]curry684 in "[ PHP/Apache] HTTP-reply conditioneel voo"[/rml]

[ Voor 15% gewijzigd door curry684 op 17-06-2003 20:47 ]

[Verwijderd]

Limhes schreef op 17 June 2003 @ 20:24:
En om de HTTP-puristen onder ons tevreden te houden kun je alsnog mijn idee gebruiken en een '200 OK' header terugsturen (zoals SoulTaker al suggereerde). Dat is nl. maar een paar bytes en geldige HTTP.

Hoe doe ik dat, met 'header unset'?'

[ACM]

Soultaker schreef op 17 June 2003 @ 19:26:
Je kunt je response beperken tot een regel met "200 OK" erop (en twee newlines)

Ik neem aan dat dat niet kan met Apache? Zonee, hoe zou het met Apache moeten dan? Ben ik wel benieuwd naar

[Verwijderd]

ACM schreef op 17 juni 2003 @ 23:13:
[...]

Ik neem aan dat dat niet kan met Apache? Zonee, hoe zou het met Apache moeten dan? Ben ik wel benieuwd naar

Ik ben ook erg benieuwd.....