הכירו את IIS URL Rewrite 2.0

29/11/2010 | | תגובות (0)

URL Rewriteתהיתם פעם איך ניתן לשפר את חווית המשתמש ודירוגו של אתר קיים בנועי החיפוש בלי לבצע שינויים נרחבים לאתר כולו? איך לשמר כתובות ישנות של דפים שלאחר שדרוג עברו לכתובת חדשה בלי לזהם את הקוד החדש במידע אודות הכתובות הישנות?

הכירו את IIS URL Rewrite 2.0! בשונה מהגרסה הקודמת, שידעה בעיקר לתרגם כתובות מתחת לפני השטח, הגרסה החדשה מהווה חבילת פתרונות שיכתוב וניתוב עשירה עם ממשק ניהול מוטמע בממשק הIIS. כעת, נדרשים רק קליקים ספורים כדי לבצע פעולות שיכולות לשדרג משמעותית את האתר, הן עבור הגולשים – שיקבלו כתובות URL הגיוניות, והן מבחינת מנועי החיפוש ע"י ביטול תוכן כפול, והכנסת מילות מפתח לURL עצמו.

קנוניקליזציה של הדומיין

קנוניקליזצית (canonicalization) הדומיין היא בעצם, הגדרה של הדומיין המועדף. כידוע, מקובל שלכל אתר ניתן לגשת ע"י אחת משתי הכתובות: www.domain.com וdomain.com (אא"כ, במקרים נדירים, הוגדר אחרת).

כמה מוזר שזה נשמע, מבחינה טכנית אלו שני סאב-דומיינים שונים. וכך, הזחלן רואה את אותו התוכן זמין בשתי כתובות שונות!

יתרה מזאת, אם לדוגמא הטמעתם את כפתור הLike של פייסבוק בעמוד באתרכם (נגיד article.html), מונה הלייקים יהיה שונה עבור: www.domain.com/article.html וdomain.com/article.html שכן, הם שני URLים שונים.

אז מה עושים?

כדי להגיע להגדרות הURL Rewrite של אתר יש לפתוח את ממשק הניהול הIIS או בשמו: Internet Information Services Manager. לבחור את האתר עליו רוצים להחיל את ההגדרות החדשות, שם תראו את האייקון של URL Rewrite.

IIS URL Rewrite icon

לפניכם יוצגו שתי רשימות: האחת Inbound rules, שבה יופיעו הכללים שיקבעו מה צריך לקרות כשפונים לURL מסויים בשרת, והשנייה Outbound rules, שתקבע מה לעשות עם URLים (לינקים וכדו') המופיעים בדפים שמוחזרים ע"י השרת.

add ruleהיות ועבור כלל הקנוניקליזציה יש תבנית מובנית, נשאר רק להליק על Add Rule בפאנל בצד ימין של המסך, ולבחור בCanonical domain name.

בחלון שיפתח יש להזין את הדומיין הרצוי (לדוגמה www.domain.com) וOK! מעתה כל מי שיגלוש לdomain.com יופנה ע"י הפניית 301 לwww.domain.com.

מה בעצם קרה פה?

אם תפתחו את web.config של האתר שאותו הגדרתם, אתם תגלו שנוספו שם כמה תגיות חדשות,

וליתר דיוק הקוד הבא:

<system.webServer>
    <rewrite>
        <rules>
            <rule name="CanonicalHostNameRule1">
                <match url="(.*)" />
                <conditions>
                    <add input="{HTTP_HOST}" pattern="^www\.domain\.com$" negate="true" />
                </conditions>
                <action type="Redirect" url="http://www.domain.com/{R:1}" />
            </rule>
        </rules>
    </rewrite>
</system.webServer>

קצת הסבר: התגית rewrite מכילה את כל הכללים (rules) הקובעים מה לעשות אם שאילתות HTTP נכנסות. לכל כלל (rule) יש שם (אטריבוט name) לצורך זיהוי.

התגית match קובעת ביטוי רגולרי של "התאמה" עבור כתובת URL הנכנסת (רק לחלק הpath שלה), הגדרה זו נועדה "ללכוד" קטעים מהURL המקורי על מנת להעבירם להמשך עיבוד (ע"ע action).

קבוצת conditions כשמה, מכילה רשימה של תנאים שכולם חייבים להתקיים כדי שהכלל יוחל על השאילתה הנוכחית. במקרה הזה ישנו תנאי יחיד: משתנה השרת HTTP_HOST צריך לא להתאים (negate="true") לביטוי הרגולרי "^www\.domain\.com$". או בעברית, כל פנייה לאתר שלא באמצעות www.domain.com. בpattern ניתן להשתמש בביטוי רגולרי או בסינטקס כוכבית.

action הוא החלק שבו קורה כל האקשן, כאן אנו אומרים לIIS מה לעשות עם השאילתא הנוכחית (במקרה שהיא עונה על כל התנאים שלעיל). האטריבוט type מציין שאנחנו רוצים לעשות הפניית 301 לכתובת המצוינת באטריבוט url. שימו לב, שבסופו של הערך של url מופיע הביטוי {R:1}. הוא מתייחס לקבוצה הראשונה שלכדנו ע"י הביטוי הרגולרי בmatch! כלומר, אם לדוגמה, הURL המקורי היה domain.com/about.html אזי, התוצאה תהיה הפניית 301 לכתובת www.domain.com/about.html! [בהרחבה בנושא]

ישנם עוד מספר תבניות מובנות עבור כללים שימושיים:

הפיכת כל הURLים הלטיניים לאותיות קטנות

בעיית האותיות הגדולות והקטנות בURL הלטיניים היא נושא ידוע, לדוגמה, שני הURLים הבאים מחזירים את אותו התוכן:

  • www.domain.com/index.html
  • www.domain.com/INDEX.HTML

הפתרון, בדיאלוג Add Rule בקטגוריית SEO ישנה תבנית בשם "Enforce lowercase URLs". וOK!

חשוב לזכור! באתרים רבים, באמת ישנו הבדל בין אותיות גדולות לקטנות, וכלל זה יכול לשבש את פעילותו התקינה של האתר.

הוספת או הסרת סלש בסוף הURL

גם הסלש "/" שמסיים את הURL עלול ליצור בעיית SEO, לדוגמה, שני הURLים הבאים מחזירים את אותו התוכן:

  • www.domain.com/en
  • www.domain.com/en/

בדיאלוג Add Rule בקטגוריית SEO חפשו את התבנית "Appedn or remove trailing slash symbol". כל שנותר לעשות הוא לבחור האם אתם רוצים את הסלשים או לא וOK!

פתרון לבעיית כפילות תוכן בדף בית של אתר

כפי שכבר כתבתי בעבר, קיימת בעיית כפילות תוכן בדף המוגדר כדף בית של האתר. שכן, שתי הכתובות הבאות מכילות את אותו התוכן!

  • www.domain.com
  • www.domain.com/index.html

בעיה זו ניתן לפתור ע"י הפניית כל הפניות מindex.html לwww.domain.com באמצעות הכלל הבא:

<rule name="DefaultDocumentToRoot" patternSyntax="ExactMatch" stopProcessing="true">
  <match url="index.html" />
  <action type="Redirect" url="/" />
</rule>

שימו לב! בדפי ASP.NET (לדוגמה default.aspx) הפנייה זו תגרום להשבתת מנגנון הPostBack של ASP.NET, שכן הaction של הform בדפים אלו מוגדר לשם הדף (ולא לכתובת שדרכה הגענו לדף) ולכן כשהדפדפן מחזיר את מידע הform לדף default.aspx הוא מקבל תשובת 301 וכל תוכן הform הולך לאיבוד!

איך לגרום לIIS URL Rewrite לעבוד עם ASP.NET WebForms?

הפתרון לבעיה דווקא פשוט! החל מASP.NET 3.5 SP1 למחלקה HtmlForm קיים מאפיין Action, דרכו ניתן לקבוע ידנית לאיפה אנחנו רוצים שהמידע של הform יישלח.

כל מה שנותר לעשות הוא להוסיף לדף את הקוד הבא:

protected void Page_Load(object sender, EventArgs e)
{
    form1.Action = Request.RawUrl;
}

במקרים של שימוש נרחב בURL Rewrite יהיה מומלץ ליצור מחלקה שממנה יירשו כל הדפים באתר ולהחיל את הפתרון עליה.

בעיה נפוצה נוספת היא לאימות לWebResources.axd של ASP.NET. אם אחד הכללים ישנה את כתובתו, רכיבים חיוניים של ASP.NET עלולים לא להיטען. לכן בכל כלל שעלול להשפיע על הקובץ הנ"ל יש להוסיף את התנאי:

<add input="{URL}" negate="true" pattern="\.axd$" />

למידע נוסף ראה: תאימות IIS URL Rewrite וASP.NET WebForms.

מה ההבדל בין IIS URL Rewrite לבין ASP.NET Routing

במבט לכאורה שני מנגנונים האלו עושים עבודה דומה – שניהם מאפשרים לאתר להציע כתובות ידידותיות למשתמש ולמנועי החיפוש. למרות זאת קיימים הבדלים יסודיים בין שתי הטכנולוגיות.

מבחינה טכנית

IIS URL Rewrite

  • הינו מנגנון "שכתוב" (rewrite) טהור, הוא עוסק בהמרה ומיפוי של כתובות URL שונות.
  • פועל בשלב המוקדם ביותר ברצף הביצוע של IIS, באירוע BeginRequest.
  • לא ניתן להרחבה מצד היישום.

ASP.NET Routing

  • הוא יותר מנגנון של מיפוי "מטפלים" לURLים.
  • פועל בשלב מאוחר יותר, באירועים ResolveRequestCache וMapRequestHandler.
  • פתוח ומיועד להרחבה מצד היישום.

מבחינה מעשית

  1. IIS URL Rewrite מיועד לשימוש עם כל טכנולוגיה, בין ASP.NET, PHP, ASP וקבצים סטטיים. בASP.NET Routing אפשר להשתמש רק מיישומים מבוססי NET.
  2. IIS URL Rewrite פועל בצורה זהה ללא הבדל בין Integrated mode לבין Classic mode. בASP.NET Routing נדרשות הגדרות מיוחדות כדי להתאימו לClassic mode.
  3. בנוסף לשכתוב URLים IIS URL Rewrite יכול גם לבצע הפניות, להחזיר קודי מצב מתואמים אישית, ולבטל שאילתות. משא"כ ASP.NET Routing.

אין לי גישה לIIS Manager מה אני יכול לעשות?

במקרים מסוימים, לדוגמה באחסון, לא תהיה לכם גישה לIIS Manager, זה לא אומר שאתם לא יכולים עדיין להגדיר URL Rewrite…

קודם כל, כפי שציינתי, ניתן לייצור כל כלל ע"י עריכה ישירה של web.config. אבל בדרך כלל לא יהיה צורך להגיע לכך, שכן Visual Studio יודע לעבוד מול פרויקטים שיושבים בIIS המקומי. כל שעליכם לעשות הוא לפתוח את הפרוייקט בIIS המקומי, וכך תקבלו גם את אפשרויות הdebug של Visual Studio וגם את ממשקי הניהול של IIS.

כמובן קודם יש לוודא שURL Rewrite 2.0 אכן מותקן בשרת האחסון שלכם.

קטגוריות: .NET | .NET 4.0 | IIS | Tools
תגיות: , , , , ,

הוסף תגובה




biuquote
  • תגובה
  • תצוגה מקדימה
Loading