I'm bumping this thread because it's still a problem for me.  Maybe
Vince can respond since I think he wrote the filter.  Right now this
URL gets me cgi.query_string as "":

http://www.example.com/index.cm/go/home/?referrer=google

It has to do with the filter passing NULL as the query string.

.pjf

--

I'm using the SES filter that is included with the core on Tomcat
6.0.18 and Open BD 1.1.  It is configured like this:

<filter>
    <filter-name>SearchEngineFriendlyURLFilter</filter-name>
    <display-name>SearchEngineFriendlyURLFilter</display-name>
    <description>SearchEngineFriendlyURLFilter</description>
    <filter-
class>com.newatlanta.filters.SearchEngineFriendlyURLFilter</filter-
class>
    <init-param>
        <param-name>extensions</param-name>
        <param-value>cfm,cfml</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>SearchEngineFriendlyURLFilter</filter-name>
    <url-pattern>/index.cfm/*</url-pattern>
</filter-mapping>

It's works like a champ on my Mach-II application except for the
problem that query string parameters are not being passed through.
The cgi.query_string is an empty string and a dump of the url scope is
empty as well when using SES URLs *with* query strings.  So URLs like
this break:

http://www.example.com/index.cm/go/home/?referrer=google

This doesn't seem be expected behavior and the RFC spec says the query
string should be there even with the path info defined so I'm thinking
this is a problem with the filter.  Thoughts?

I did a little digging in the Java source and I found this:

public String getQueryString() {
        // The wrapped request needs to return null so that only the
query
string from the
        // original request will be used. If we don't return null here
then
this query string
        // will be appended to the original query string in
cfUrlData.decodeURIString()
        // causing duplicate parameter values.
        return null;

}

Looks like this *might* be the problem? Or is it my configuration?

TIA,
.Peter

On Jun 17, 11:29 pm, "Peter J. Farrell" <[email protected]> wrote:
> Based on the code, the SESFilter does not translate the path info into
> the querty but takes that information and makes sure it's in the
> cgi.path_info variable.  Even the header notes state that:
>
> >  * This filter is used to allow BlueDragon to process search engine
> > friendly
> >  * URLs. An example of this is /bdj2eedev/index.cfm/year/2006. This
> > filter will
> >  * forward a request like this onto BlueDragon with a ServletPath of
> > /index.cfm
> >  * and PathInfo of /year/2006.
>
> The problem is the query string is available, but for some reason it's
> not getting passed on. Comments in the file say this:
>
> > // The wrapped request needs to return null so that only the query
> > string from the
> > // original request will be used. If we don't return null here then
> > this query string
> > // will be appended to the original query string in
> > cfUrlData.decodeURIString()
> > // causing duplicate parameter values.
> > return null;
>
>  From what it looks like, the filter should *not* return null any longer
> because the cgi.query_string is "" (zero-length string) when dumping the
> cgi scope in .cfm page that usesSESURLs and has query string parameters.
>
> Either the filter should pass the query string along or the
> cfUrlData.decodeURLString() has a defect in it.
>
> .Peter
>
> Matthew Woodward said the following on 06/17/2009 09:22 PM:
>
> > Peter J. Farrell wrote:
> >> So URLs like
> >> this break:
>
> >>http://www.example.com/index.cm/go/home/?referrer=google
>
> >> This doesn't seem be expected behavior and the RFC spec says the query
> >> string should be there even with the path info defined so I'm thinking
> >> this is a problem with the filter.  Thoughts?
>
> > Interesting--my initial reaction is that I'm not sure how you'd mix
> > and match /name/value with ?name=value. In other words as I look at
> > it, it makes sense that it'd break because if you translate this out,
> > it becomes:
> >http://example.com/index.cfm?go=home?referer=google
>
> > So the question is should theSESfilter figure that all out or is
> > that just a URL syntax that doesn't make sense?
>
> > To put it another way, if you're usingSESURLs, why are you not using
> > this as the URL?
> >http://example.com/index.cfm/go/home/referer/google
>
> > I know that's not an answer but I thought it might kickstart any
> > underlying technical discussions that need to happen.
>
>
--~--~---------~--~----~------------~-------~--~----~
Open BlueDragon Public Mailing List
 http://groups.google.com/group/openbd?hl=en
 official site @ http://www.openbluedragon.org/

!! save a network - trim replies before posting !!
-~----------~----~----~----~------~----~------~--~---

Reply via email to