Har på många tidigare projekt använt Id-nummer i url:erna för att IIS och .NET haft så dåligt stöd för att skapa användarvänliga url:er. Gör nu om en del gamla sidor till ASP.NET MVC och lägger över dem till IIS 7-servrar som har bättre stöd för url-omskrivning.
Brukar lägga till ett speciellt databas-fält för att spara den sista delen av url:en som ska vara till för att identifiera blogginlägget, produkten, kategorien eller vad det nu handlar om och basera denna på den äldre titeln. Använder det uttryck som även Wordpress använder för att beskriva ett sånt fält, "Slug".
Här är ett skript som jag precis körde på en sådan databas. Detta byter ut de tecken jag inte vill ha i url:erna mot ett vanligt bindestreck, gör om allt till gemener och byter ut å,ä,ö mot a,a,o.
UPDATE BlogPost SET Slug=Lower(Title);
UPDATE BlogPost SET Slug=REPLACE(Slug,'å','a');
UPDATE BlogPost SET Slug=REPLACE(Slug,'ä','a');
UPDATE BlogPost SET Slug=REPLACE(Slug,'ö','o');
UPDATE BlogPost SET Slug=REPLACE(Slug,' ','-');
UPDATE BlogPost SET Slug=REPLACE(Slug,'&','-');
UPDATE BlogPost SET Slug=REPLACE(Slug,'/','-');
UPDATE BlogPost SET Slug=REPLACE(Slug,'-','-');
UPDATE BlogPost SET Slug=REPLACE(Slug,'.','-');
UPDATE BlogPost SET Slug=REPLACE(Slug,',','-');
UPDATE BlogPost SET Slug=REPLACE(Slug,'_','-');
Som standardinställning visar IIS7 rätt tråkiga felmeddelande när en sida inte kan hittas och ser ut som på bilden här under. Just nu ser denna bloggens 404-sidor ut precis så där, så vi ska försöka fixa något roligare. Detta inlägg kommer visa hur man gör för att ställa in servern så att man ska kunna visa en egen design istället.
Gå in på den webbplats som ska konfigureras och klicka på Error Pages. Följ sedan instruktioner på följande bild. Klicka Edit Feature settings... och välj Detailed Errors.
Så nu ska jag bara skicka iväg denna post till vårt webbhotell så fixar de nog de inom kort.
Sen var det där med egen design. Kommer nog inte hinna få till med något jättespännande. Om du vill se exempel på riktigt snygga och roliga 404-fel-sidor kolla in Smashing Magazine som har några riktigt finasamlingar.
Råkade ut för det idag att möjliga uppkopplingar tog slut på en server. Tänkte att det är väl ingen fara eftersom jag har mitt gamla knep som brukade gå att köra från en XP-burk.
Men tyvärr inte heller det gick denna gången och jag fick bara "The terminal server has exceeded the maximum number of allowed connections" tillbaka som svar.
Som tur skedde det under dagtid så jag kunde ringa vår support. Men när såna här grejer sker under nattliga uppgraderingar kan det bli riktigt jobbigt.
Jag ställde därför in Terminal Services Configuration på alla våra servrar så att oaktiva uppkopplinga kommer självdö efter tre timmar. Hittade en bra beskrivning hos TechnoBuff.
Skrev en beskrivning om hur man gör ISAPI Rewrite 3 på Bineros servrar och tyvärr innehåll denna några fel. Så om någon har provat beskrivningen utan lycka så kan jag rekommendera att kolla in ändringarna på den länken och så kommer det nog gå mycket bättre.
ISAPI-reglerna ska bland annat ligga i en fil vid namnet .htaccess och inte httpd.ini som jag skrev först.
Vi har börjat testa lite smått på några webbsajter att använda ISAPI-modulen som finns installerad hos Binero och det fungerar ganska bra. Vi har till och med fått igång ett första MVC-projekt på .NET 3.5. Riktigt kul med ett webbhotell som är framåt och förstår vilken teknik vi utvecklare vill ha.
Det tog lite tid att lista ut hur man fick igång det eftersom Bineros förklaring av Rewrite 3 inte är så utförlig. De har manualen på deras sajt så där kan man lära sig lite (funkar dock inte med Firefox 3). Helicon Tech som ligger bakom modulen rekommenderas också.
Mest hjälp för att få igång det hade jag av av några trådar på Aspsidan och webForum.
Något att tänka på är att de ändringar man gör i Script Mappings i Bineros kontrollpanel tar ett tag innan de slår igenom. Kommer ihåg den första kvällen då jag kämpade med det in på småtimmarna men hade ingen lycka. Provade mängder av olika konfigurationer och gav sist upp och bara lämnade det. Nästa morgon när jag laddade upp sidan så bara det fungerade!
Så nu ska jag förklara det jag kommit på hittills.
Det första man måste göra är att lägga till en *-mappning enligt följande.
Filetype: * Executable: Aspnet2 is wildcard: false is script engine: false verify that file exists: false
När du ändå är där kan du även lägga till .asax eftersom Binero verkar ha glömt det i standardinställningen. Se bilden för exempel på de två inställningarna längst ner.
Sen är det dags att knåpa ihop en httpd.ini (uppdatering: filen ska ha namnet .htaccess och inget annat) som styr hur ISAPI Rewrite 3 ska uppföra sig. Här under ser ni våran som fungerar fint om man vill ta bort .aspx ändelserna. Jag har dock inte lyckats att exkludera vissa mappar, så om någon kan se vad det är för fel på sista raden som ska blocka mappen "MappSomInteSkaOmskrivas" så uppskattar jag tips. Uppdatering: Denna rad måste ju givetvis ligga överst för att de andra reglerna ska ignoreras. Har nu uppdaterat skriptet som det ska se ut och då funkar det mycket bättre.
# Helicon ISAPI_Rewrite configuration file # Version 3.1.0.34
Har ägnat nån timme åt att försöka skicka mail med SMTP-servern i IIS 5.1 och nu lyckats få iväg några mail. Här går jag igenom de steg jag fick göra för att få det att fungera.
Mailkoden
Själva mailkoden jag använder i applikationen använder System.Net.Mail och ser ut ungefär så här:
SmtpClient smtpClient = new SmtpClient("localhost"); //smtpClient.DeliveryMethod = SmtpDeliveryMethod.PickupDirectoryFromIis; MailAddress from = new MailAddress("from@dummysite.domain", "Alias from name"); MailAddress to = new MailAddress("to@dummysite.domain"); MailMessage mail = new MailMessage(from, to); mail.IsBodyHtml = true;
mail.Subject = "From my local computer"; mail.Body = "Testing, testing";
smtpClient.Send(mail);
"SmtpDeliveryMethod.PickupDirectoryFromIis" var något jag trodde behövdes ett tag, eftersom jag läste om det på ett forum, men det visade sig att det gick bra att skicka även utan.
Ställa in SMTP-Server
Det problemet kom i form av ett felmeddelandet som såg ut så här:
Mailbox unavailable. The server response was: 5.7.1 Unable to relay for ...
Lösningen till detta hittade jag på CodeBetter och innebar att lägga till 127.0.0.1 som giltigt IP-nummer för att skicka mail från SMTP-server. (Egenskaper / Åtkomst / Anslutning / Endast datorer i listan nedan)
När detta var klart så försökte jag skicka igen, nu fungerade det i applikationen men mailen fastnade i C:\Inetpub\mailroot\Queue.
Lösningen på detta fann jag på Velocityreviews där medlemmarna förklarade att man behövde lägga till en giltigt SMTP från sin ISP. (Egenskaper / Leverans / Avancerat / Smart värd)
Hoppas detta kan hjälpa någon som vill kunna skicka mail från sin egen dator med ASP.NET.
Idag larmade en av våra webbservrar för att utrymmet på C:-disken höll på att ta slut. När jag var inne och letade efter utrymme att frigöra hittade jag logg-filer i [%windir%\system32\LogFiles\HTTPERR] som jag inte visste att de fanns. Och de tog relativt stort utrymme.
Här loggas alla fel som sker i HTTP och inte kan tas hand om applikationen. En intressant källa att söka i med andra ord och då kan det vara bra att ha ett verktyg för att logganalys eftersom filerna är stora.
Det var hos Chrison.net som jag först hittade dessa tips. Hos Microsoft kan man läsa mer om errorloggen för HTTP API och där finns även instruktioner för hur man byter plats på loggfilerna. I mitt fall vill jag hellre ha dem på en disk som är dedikerad för loggfiler och inte på huvuddisken som innehåller operativsystemet.
När man söker igenom stora textfiler som t ex loggfiler kan det vara bra att ha något specialverktyg till sin hjälp. Det finns säkert massor av såna här program, men tänkte skriva om två stycken som jag provat.
Microsoft Log Parser 2.2 verkar bra, speciellt eftersom den är gjord för att hantera Microsofts egna format på loggfilerna. Tyvärr sker input genom ett CMD-fönster och därför lite väl omständigt att använda enligt mig.
Kollade istället på ett enklare alternativ. Delay släppte igår första publika versionen av sitt verktyg som heter TextAnalysisTool.NET. Har precis testkört det och gillar det verkligen. Genom ett enkelt gränssnitt kan man ladda in loggfiler och sedan välja ut vissa rader man vill granska mer utförligt genom att ange Regular Expressions.
Har testa lite med att streama Flash video med FLVPlayBack-komponenten och det fungerar väldigt bra. För att konvertera andra format till .flv så kan man använda Adobe Flash CS3 Video Encoder eller importera direkt till Flash CS3.
När jag sedan skulle köra igång videospelare till webbhotellet som sajten i fråga ligger på blev det lite problematiskt. Videon ville inte spela alls.
Efter ett tag kom jag på att IIS6 inte har den rätta MIME-typen tillagd som standard och webbhotellet inte lagt till denna. Som en nödlösning fick jag lägga själva .flv-filerna på en server som jag hade kontroll över, fixa lite crossdomain.xml-"magik" och lägga till MIME-typen på denna externa server.
Adobe har en bra beskrivning till hur man lägger till rätt MIME-typ för .flv på IIS6 och de rekommenderar att man mappar .flv-ändelsen mot "flv-application/octet-stream". Jag har även testat med "video/x-flv" som också fungerar bra.
Vi har pratat mycket om användarvänliga url:er här på bloggen. Ni som har hängt med på ämnet vet att Microsofts ASP.NET-teknik inte är så optimal för att göra användarvänliga länkar.
Scott Guthrie som är utvecklingschef på Microsoft gör sitt bästa för att hålla modet uppe för alla url-designande freaks där ute. Vi har väntat länge på en lösning och nu kommer den snart i form av Longhorn Server och IIS 7.0.
Scott gjorde i måndags en genomgång av nya finesser i webbservern IIS 7.0 och visar även ett diagram hur processmodellen skiljer sig från den tidigare IIS 6.0. Samtidigt klargörs ytterligare en gång att IIS 7 inte kommer att finnas tillgänglig på Windows 2003.
Så det är väl bara att vänta på det nya serveroperativet då och alla de förbättringar som det kommer att ge.
Det som är bra är att man i alla fall får ordentligt med tid på att tänka igenom exakt hur man vill ha sina url:er när möjligheten finns att förbättra dem. Jag har tidigare spånat lite på hur jag vill ha urler:na till denna bloggen i kommentarerna till en tidigare tråd på ämnet.
Som ett exempel har just detta inlägget du läser just nu adressen:
http://codeodyssey.se/blog.aspx_id=270
Det säger ingenting om innehållet av artikeln för en besökare och det är det jag vill förbättra i första hand. Istället tycker jag att detta skulle vara en snyggare och mer tillgänglig adress.
Jag har fortfarande inte bestämt mig helt hur jag ska hantera alla specialtecken som inte stödjs i url:formatet. En som har funderat mer på dessa är Scott Hanselman och han bjuder idag på riktigt intressant läsning i sin artikel "Are Blog URLs important". Scotts blogg har rätt sjyssta url:er men dras fortfarande dras med .ASPX-ändelsen.
Det finns ju några genvägar mot snyggare adresser men vi känner att det bästa skulle vara att vänta tills IIS 7.0 kommer och man kan få till adresserna precis som man vill ha dem med en gång.Adresserna bör ju aldrig ändras så att göra några halvmessyer känns inte aktuellt.
Men för er som länkar till oss kan vara lugna. De url:er vi har just nu, kommer fortsätta att fungerar, även när vi lanserar de mer besökarvänliga varianterna. Trasiga länkar är inget kul.
