Thread

P.J. - at this point I’m going to have to recommend that, instead of trying to fix it through more template additions, you actually reduce the template and find out what the actual problem is. 

It seems right now that you’re pretty much shooting in the dark.  Start with a minimal template and build it up, that should tell you where the issue is and we can help from there.

hi, Greg & Lisa,

I think I found a solution that is easy to implement and does away with PHP entirely.

My solution is to use htaccess to screen out all invalid URL that has a backslash character, using the following:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^(.*)\\(.*)/?$ /errors.shtml [F]
</IfModule>

My questions are:

1. Admitting that this is a bandaid solution, is that any DANGER to this?
2. Will this obstruct somehow search engines (such as Google), caching (by EE or Internet Archive, etc.) or other indexing bots?
3. Are there any security concerns to this approach, from EE’s prespective?

Thanks.

P.J.,

Again, that is another bandaid solution as you admit yourself. While it seemingly works, I can’t answer your questions for sure because we don’t know what the underlying problem is.

Start with a minimal template and build it up, that should tell you where the issue is and we can help from there.

This is the advised route we can help you with

Adding to what the others said above, backslashes are not valid in a URL on their own and must be url encoded. This is the % 5C you are seeing. This is expected and standard behavior.

Thanks to all the EE staff who have posted here. Your help is truly appreciated.

I have since experimented a bit with how I got myself into such trouble. It appears that the problem is related to the use of segment variables (that are made available by EE) with complex PHP conditionals and PHP character/string functions.

here is one example:

<?php
if (ctype_digit("{segment_3}") == TRUE OR (substr("{segment_3}", 0, 1) == "C" AND ctype_digit(substr("{segment_3}",1)) == TRUE))
{
?>{if (segment_2 == "section1" OR segment_2 == "section2" OR segment_2 == "section3")} i_am_doing_something_here {if:else} i_am_doing_something_elsewhere {/if}
<?php
}
?>
some_stuff_here
<?php
if (("{segment_1}" == "section6" && "{segment_2}" == "image" && ctype_digit("{segment_3}") == TRUE && "{segment_3}" != "0") OR ("{segment_1}" == "mysite" && ("{segment_2}" == "section1" OR "{segment_2}" == "section2" OR "{segment_2}" == "section3") && ctype_digit("{segment_3}") == TRUE && "{segment_3}" != "0"))
{
?>
i_am_doing_morethings_there
<?php
}
?>

obviously, the above codes were “modified” to remove sensitive data. i am aware that the code is ugly, but it seems that the complex conditionals and the mixture with the segment variables are the culprit.

P.J. - care to elaborate what your ultimate goal for this code is?

Hi, Sue and other EE staff,

The original intent of these codes was to make sure that the url follows a certain format and ONLY those URLs will yield a non-error page. The intended format was the following:

segment 1 = is this a weblog or image gallery?
segment 2 = if weblog, which subsection? if image, which subgallery?
segment 3 = only a number (no non-numerics, except for pagination or category)**, identifying the entry ID or image ID or category ID

Many of the complex conditional is to help to determine the appropriate title for the page that depends on these segments.

**The segments also make provisions that segment 3 may begin with either a C (for category) or P (for page) so that in some cases these non-numerics are also valid. This explains why I am using substr and ctype_digit in PHP to test specific characteristics of the URL segments.

Somehow using these added PHP functions with the built-in EE segment variables is creating a problem with the interpretation of backslash (in Firefox, which unlike Opera or IE, does not convert to a forward slash) causing EE to report a PHP error.

Hi, P.J.,

As you likely know,  ExpressionEngine has its own built-in way of looking at URLs, it looks like you’re trying to do something entirely different.  This is something we discourage.

At this point since you’re custom scripting this, I’m going to move this up to How to; these simply aren’t EE features and you’re working against EE in this case.  You might try to re-consider your approach and see if you can work more in-line with how EE treats URLs.

I have been asked by mods here as to why my approach is or is not inline with how EE treats URL.

I submit that my URL handling is entirely INLINE with how EE treats URL.

With EE default settings, segment 1 describes whether or not it is a weblog or image gallery (as in my case), segment 2 describes templates (as I call it, sections, in my case), segment 3 describes the entry itself (be it a post or an image).

Segment 3 can also hold pagination and category markers that begin with the characters “P” and “C” respectively (also in my case).

My PHP rules are there to “enforce” and “check” that all incoming/referring URLs follow this format, so that an URL with word titles in segment 3 will not lead to a post. Here, EE allows segment 3 to be either characters or numerics; I simply want to ONLY use numerics, so that any URL with non-numeric segment 3 (notwithstanding pagination and category makers) will be redirect to an error page.

Thus, I believe this is entirely within EE designed feature of how URL is handled and is therefore a technical issue. 😉

With EE default settings, segment 1 describes whether or not it is a weblog or image gallery (as in my case), segment 2 describes templates (as I call it, sections, in my case), segment 3 describes the entry itself (be it a post or an image).

You’re incorrect here.  Here is a break-down:

Segment 1: Template group
Segment 2: Template
Segment 3: Category Trigger, URL Title, or Entry ID

If you’re using these as described then no PHP is needed.  Perhaps you can tell us, in plain English, what you are after with your PHP conditionals.

huh?

My segment 1 describes whether it is a weblog or an image gallery. This is done by template group, per EE’s default (in fact, these were the default template groups created by earlier EE builds: one for weblog and one for gallery). Segment 2 and 3 are the same.

How is this different?

My apologies, P.J.; I had no idea that your template groups were named after your weblog or image gallery.  I’m not a mind-reader and neither is EE.  EE looks at Segment 1 for the template group only; if you made a relationship between group and content, then that is great and well within EE’s default URL structure.

So, that PHP script - it is a custom PHP and we can not support the custom PHP, but perhaps you can explain in plain English what it is doing and we can help you come up with a less scripty solution.

Hi, Lisa,

Thank you. I understand. 😉

Here was my intention for the PHP rules, as I had described in an earlier post:

As an example, in this URL: www[dot]mysite[dot]com/segment1/segment2/segment3/

My PHP rules are simply to “enforce” and “check” that all incoming/referring URLs follow this format, so that an URL with word titles in segment 3 will not lead to a post. Here, EE allows segment 3 to be either characters or numerics; I simply want to ONLY use numerics, so that any URL with non-numeric segment 3 (notwithstanding pagination and category makers) will be redirect to an error page.

The problem I am now encountering is that EE throws out a PHP error in malformed URL that includes a backslash. Some of the malformed URLs are:

www[dot]mysite[dot]com/segment1/segment2/segment3\/
www[dot]mysite[dot]com/segment1/segment2/\segment3/
www[dot]mysite[dot]com/segment1/segment2\/segment3/
www[dot]mysite[dot]com/segment1/\segment2\segment3/
www[dot]mysite[dot]com/segment1\/segment2/segment3/

Does this help to clarify?

Hi, P.J. - there are built-in functions for this.  Please read about Strict URLs, 404 pages, and require_entry with the no_results conditional.

It will look for valid template group, template, and URL Title/Entry ID.  I think that’s the root of what you want and it’s a far more direct route with built-in EE functionality.

Thanks, Lisa. I will take a look. I have not tried Strict URLs, but I am already using the others.