Uploaded image for project: 'In-Portal CMS'
  1. In-Portal CMS
  2. INP-828

Impossible to get "404 Not Found" page with Rewrite Listeners

    XMLWordPrintable

    Details

    • Type: Bug Report
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 5.1.0
    • Fix Version/s: 5.1.3-B1
    • Component/s: Front End
    • Labels:
      None

      Description

      In new rewrite listener engine it's near to impossible to get 404 Not Found page in case if at least one part of url was interpreted by rewrite listener. For example in if have urls in format "/friends/<friend_name>" (friend detail page) and we have "/friends" (friend list). At parsing start we look for "friends" at url start if so, then appropriate FriendRewriteListener begins to parse. If there are no more url parts, then show list. If there is more part, then threat it as friend name and display it's page. In case if friend not found we should normally display "404 Not Found", but instead we do nothing and assuming, that next rewrite listener will take care of that, because it really could do that, who knows.

      [B]For example:[/B]

      http://www.website.com/articles/not_found_article.html and http://www.website.com/articles.html will lead to the same page and Google doesn't like that.

      [B]Proposed Solution[/B]

      To solve this problem I propose to let rewrite listener mark url parts, that are processed by it (part order number). At the end in case if total processed part count doesn't match count part in url we will automatically show 404 Not Found page.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                alex Alex
                Reporter:
                dmitry Dmitry Andrejev [Intechnic]
                Developer:
                Alex
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: