[Squid in Smoothwall/SME] verandert HTTP response-codes?

[Eegee]

Hallo,

Ik werk bij een softwarebedrijf en heb een client-programma geschreven dat onze software automatisch updatet. Dit gaat over standaard http-verkeer, poort 80.

Update-pakketten worden op de server als zip-file aangemaakt. Het zippen duurt even, dus ik heb een status-check ingebouwd; de client controleert om de 2 seconden wat de status van het zippen is via een URL.
Op die status-URL heb ik in eerste instantie code 200 gebruikt, maar dan geen reason-phrase OK, maar Bezig (indien nog bezig) of Klaar als de zip-file gereed staat.

Bij een klant van ons bleek dit niet goed te werken, zij kregen gewoon 200 OK door, dus de check op 'Bezig' of 'Klaar' ging de mist in. Dit zag ik in een logfile dat aangemaakt is door de client-software. Dit loggen heb ik ingebouwd om te weten wat er speelt als er problemen zijn, dus om dan te kunnen debuggen.

Die klant draait een Linux Smoothwall (www.smoothwall.org) met daarin een transparante squid-proxy/cache. Dit heb ik nagevraagd nadat ik in het logfile zag staan: X-Cache: MISS from <proxycomputer>.

Nu dacht ik, dan ligt het misschien aan het gebruiken van 200 Bezig ipv 200 OK. In ieder geval iets om te testen. Dus ik ben maar eens overgestapt op code 202 voor bezig en 201 voor klaar. Ik heb er ook nog voor gezorgd dat alles via HTTP/1.1 verloopt en niet via 1.0.

Maar dan nog blijkt de proxy/cache het resultaat te veranderen naar HTTP/1.0 (!) en 200 OK! Het lijkt er voor mij dus op dat alles > 200 gewoon naar 200 wordt vertaald?!

Bij een tweede klant, die SME Server gebruikt (www.contribs.org , ook zoiets als Smoothwall en ook met Squid), treedt precies hetzelfde probleem op (en ook zo'n X-Cache: MISS from ... header in het debug-log).

Van andere klanten heb ik niet over dit probleem gehoord, daar zullen de http response-codes niet veranderd worden, maar die zullen waarschijnlijk geen transparante cache gebruiken.
Zelf ben ik dit ook niet tegengekomen tijdens ontwikkelen. Ik heb Ethereal gedraaid naast de client, en ik krijg gewoon 201/202 binnen op de goede manier.
Ik heb nog niet zelf getest met een transparante squid-proxy. Dit zal ik wellicht alsnog moeten doen, maar dan moet ik om een test-PC vragen waar ik SME of Smoothwall op kan installeren.

Maar dit is toch ook niet iets waar je direct rekening mee houdt, een proxy zou dit toch niet mogen/moeten doen? Weet iemand hoe dit zou kunnen, mag een proxy zomaar een response veranderen, waarom wordt niet gewoon 201 en 202 doorgegeven met HTTP/1.1?

Als ik in de docs en source kijk van Squid zie ik dat er wel rekening gehouden is met 201 en 202 e.d., dat zou ook raar zijn als ze het niet zouden doen. Maar waarom gebeurt het dan toch?

Ik heb gezocht bij Squid, SME en Smoothwall op de forums e.d. en via Google, maar dit is zo'n probleem waar je echt precies de juiste zoektermen gebruikt moet hebben wil je iets zinvols tegenkomen... niks gevonden dus wat zou kunnen helpen of verklaren.
Ik vraag het nu eerst hier omdat ik nog niet zeker weet of het nu aan iets ligt dat ikzelf toch nog fout doe, of toch aan Squid. Of zou het ook nog aan Smoothwall of SME server kunnen liggen? Misschien hebben jullie ideeën waar ik nog niet aan gedacht heb of weten jullie van bugs af.

Zou ik misschien iets kunnen regelen met no-cache directives op bepaalde plaatsen?

[Eegee]

Tsja, dan toch maar even een
Nu weer een derde klant waar 't bij optreedt, ik weet nog niet welke proxy zij gebruiken... Uiterst raar probleem.

[Spider.007]

Kan je client dit niet oplossen door de always_direct optie (in squid.conf) op te nemen voor jouw server? Verder snap ik ook niet precies waarom squid de headers zou kunnen veranderen

[Eegee]

Dat is wellicht een optie; moet ik die klanten wel zover krijgen dat ze dit willen opgeven in hun squid.conf. De tweede klant heeft sowieso gezegd te gaan kijken of ze voor de test er omheen kunnen werken, dus daar zou ik 't aan kunnen vragen.

[ Voor 3% gewijzigd door Eegee op 14-04-2005 22:06 ]

[neh]

Spider.007 schreef op donderdag 14 april 2005 @ 20:13:
Verder snap ik ook niet precies waarom squid de headers zou kunnen veranderen

200 is geen header, 200 is een response code.

ik vind het zelf een bijzonder lelijke oplossing. is het niet mogelijk om gewoon in de body een status te plaatsen?

[ Voor 9% gewijzigd door neh op 14-04-2005 22:13 ]

[Spider.007]

Als ik jou was, zou ik sowieso beginnen met een lokale squid-instance om te testen. Hierop kun je dergelijke configuratiewijzigingen snel testen. Overigens zit ik de HTTP specs door te lezen; en dan kom ik dit tegen:

201 [...]

The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead

[...]

202 [...]

Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled

[...]

Voldoe je wel aan deze eisen? Wellicht is je app iets vergeeflijker dan squid is?

[Spider.007]

plork schreef op donderdag 14 april 2005 @ 22:11:
[...]


200 is geen header, 200 is een response code.

De responscode staat in de header

ik vind het zelf een bijzonder lelijke oplossing. is het niet mogelijk om gewoon in de body een status te plaatsen?

Volgens mij is het gebruik van de juiste HTTP statuscodes netter dan een 200 met HTML code erin? Die moet vervolgens weer geintepreteerd worden enzo; dat leid slechts tot fouten HTTP zou toch ondersteuning moeten bieden voor de gevraagde functionaliteiten?

[Eegee]

In de body is inderdaad een oplossing die altijd moet werken, alleen dat betekent dat ik het protocol voor een tweede keer moet veranderen. Tsja, achteraf was dat een veiliger keuze geweest, maar eerder leek het mij, zoals Spider.007 ook zegt, dat het toch ook met die statuscodes moet kunnen; die zijn er min of meer voor bedoeld.
Misschien dat ze daarom met XML en SOAP ook alleen maar 200 en 500 gebruiken, als ik 't goed heb...

Omdat er nu in theorie 1300+ klanten mee kunnen werken, betekent het dat er twee versies tegelijk moeten draaien, voor de huidige en de nieuwe situatie (van plork). Dat is wel af te vangen (ik geef versies mee), maar dat is gewoon weer wat lastiger met extra kans op fouten. Maar ik houd die optie natuurlijk wel open.
Ik zou liever wel eerst willen weten waarom de code nou veranderd wordt. 't is een kwestie van afwegen, als er nou nog meer klanten bij komen met dit probleem ga ik wel eraan denken om m'n protocol weer aan te passen.

Over 202/201 in de RFC: ik geef als eerste een 202, want de server start natuurlijk in status 'Bezig'. De RFC geeft voor 202 aan (volgens je quote):
(1) er moet een indicatie voor de status in zitten. Die zit erin, ik heb eerst een regel met daarin de status.
(2) Een pointer naar een status monitor, of een schatting. Die pointer zit er in op de tweede regel in de body, want dat is een URL die point naar een status monitor (hetzelfde script dat de status teruggeeft).

Het kan bij de 201 zijn dat ik nog die genoemde Content-Type moet meegeven, maar die komt toch nog niet aan bod omdat het al bij 202 fout gaat (die dus eerst wordt verstuurd). Nee trrouwens, ik geef overal text/plain mee bedenk ik me nu; dat zou toch moeten kunnen.
Het rottige is dus dat het dus ook werkt zolang er maar geen transparante inktvis tussen zit, en da's jammer.

Misschien is het dan inderdaad zo dat Squid dit ergens niet pikt. Dat vind ik dan wel raar. Dan zit er niks anders op om een lokale squid te installeren om de klant-omgeving na te kunnen bootsen (of beter Smoothwall of SME) en te kunnen testen.

[neh]

Spider.007 schreef op donderdag 14 april 2005 @ 22:16:
[...]
De responscode staat in de header

Lees de RFC er maar op na, zoals ik het interpreteer volgt de header pas na de response code. De response code is dan dus geen onderdeel van de header. Headers hebben de vorm "Naam: waarde", iets waar de status code duidelijk niet aan voldoet.

[...]
Volgens mij is het gebruik van de juiste HTTP statuscodes netter dan een 200 met HTML code erin? Die moet vervolgens weer geintepreteerd worden enzo; dat leid slechts tot fouten HTTP zou toch ondersteuning moeten bieden voor de gevraagde functionaliteiten?

HTTP hoeft niet per definitie een HTML document te transporteren. De body kan net zo goed gewoon plain text bevatten. Ook dat hoeft niet uitgebreid te zijn, je kunt daar dan een enkel getal of teken kwijt, wat me vrij simpel te interpreteren lijkt.

Dat squid de response code niet ongewijzigd meestuurt is inderdaad vreemd, maar de class van de response code 2xx blijft desalniettemin intact en een HTTP applicatie is niet verplicht de specifieke codes in een class te kunnen interpreteren. Een betere (maar toch lelijke) oplossing was geweest om twee verschillende classes te nemen voor de responses, al blijf ik achter de body oplossing staan.

[ Voor 4% gewijzigd door neh op 27-04-2005 12:30 ]