[IIS] URIQuery voor statische bestanden

[GrimaceODespair]

Het is niet echt een programmeerprobleem, maar volgens mij leunt het er wel dicht bij aan. Here goes:

In IIS kan je de stam en het querygedeelte van HTTP-requests apart laten loggen iva URI Stem en URI Query.



Dit geeft in de logs bijvoorbeeld volgende resultaat:

code:

# ... cs-uri-stem cs-uri-query ...
... /Default.aspx ItemID=1 ...

Voor statisch geserveerde bestanden, komt de log er echter als volgt uit te zien:

code:

# ... cs-uri-stem cs-uri-query ...
... /Default.gif?ItemID=1 - ...

Iets overzichtelijker wordt dat:

Soort bestand	URI Stem	URI Query
Dynamisch	Default.aspx	ItemID=1
Statisch	Default.gif?ItemID=1	-

Weet er iemand of en hoe ik de logging zo kan beïnvloeden dat ook voor mijn statische gif de URI Query correct gelogd wordt?

[Niemand_Anders]

Niet. Een statisch bestand wordt door IIS as-is doorgestuurd. IIS bouwt in dat geval niet de ServerVariables collectie op. Doordat IIS zelf dus niet de url opsplists in componenten komt dit dus ook niet los in de logs te staan.

De enigste manier waarop je dat kan oplossen is door de extenties van je statische bestand door bijv. de aspx engine te laten uitvoeren. In de web.config kun je via de httpHandlers sectie aangeven door welke class *.gif wordt afgehandeld. de class kan dan via Response.WriteFile() de image terug geven.

Maar wat ik niet begrijp, waarom geef je aan een statisch bestand argumenten mee? Wat is het nut daarvan?

[GrimaceODespair]

Niemand_Anders schreef op vrijdag 22 juni 2007 @ 10:24:
De enigste manier waarop je dat kan oplossen is door de extenties van je statische bestand door bijv. de aspx engine te laten uitvoeren. In de web.config kun je via de httpHandlers sectie aangeven door welke class *.gif wordt afgehandeld. de class kan dan via Response.WriteFile() de image terug geven.

Daar ben ik mee aan het experimenteren. Om een scripting engine te forceren, heb ik in principe de optie om de pixel te gooien door 1 van volgende engines:

• C:\WINDOWS\System32\inetsrv\asp.dll
• C:\WINDOWS\Microsoft.NET\Framework\vX.X.XXXXX\aspnet_isapi.dll
• C:\WINDOWS\System32\webhits.dll
• C:\WINDOWS\System32\idq.dll
• C:\WINDOWS\System32\inetsrv\httpodbc.dll
• C:\WINDOWS\System32\inetsrv\ssinc.dll

Het liefst zou ik dan ook nog hebben dat de gif automatisch geresolved wordt, ipv dat ik hem nog moet gaan Response.Write'n ofzo. Asp(x) valt dus af. Andere goeie suggesties?

edit:
Nu ik er zo over na denk, zal dat waarschijnlijk nooit kunnen, aangezien de script engine altijd het bestand moet interpreteren.

Maar wat ik niet begrijp, waarom geef je aan een statisch bestand argumenten mee? Wat is het nut daarvan?

Browser caching preventie. Ik gebruik de image om aan tracking te doen (ja, ik voel de golf van verontwaardiging tot hier).

---

Edit:

Overigens snap ik je argument van die scripting engine wel, maar als je even verder denkt is het toch niet helemaal logisch. Het is immer IIS zelf die je de mogelijkheid biedt om URI Stem en URI Query te laten loggen, dus zou je verwachten dat hij dat ook zelf analyseert.

Daarbij komt nog dat de URI Stem varieert naargelang je door een scripting engine gaat of niet. Met andere woorden: de scripting engine verandert een variabele die IIS intern gebruikt. Ik zou eerder verwachten dat IIS een Raw URI logt die altijd hetzelfde blijft, en, als de boel door een scripting engine gaat, extra variabelen log.

Om kort te gaan: volgens mij herkent IIS zelf dat een bestand dynamisch wordt afgehandeld, en vult aan de hand daarvan zelf de URI Stem en URI Query in. Dus wat ik nodig heb, is eigenlijk een soort null-engine die zo min mogelijk overhead introduceert.

---

oplossing

Ok dan, culprit gevonden. Ik gebruik Ionic's ISAPI Rewrite Filter voor URL rewriting. Blijkbaar zat er in de versie die ik gebruikte een, ondertussen opgeloste, bug waardoor bij het rewriten het stuk achter '?' bij de stam gelogd werd ipv als querystring.

[ Voor 35% gewijzigd door GrimaceODespair op 22-06-2007 15:20 ]