How to parse a guid from a uri to using in a redirection

when HTTP_REQEUST {
    set guid [findstr [HTTP::query] "docid=" 6 &]
    
    if { $guid ne "" } {
        HTTP::redirect "http://host.example.com/en/server/$guid"
    }
}

Naturally you should substitute an appropriate name for "host.example.com". This will not redirect if the docid query parameter is not found, and it makes no effort to validate the GUID.

when HTTP_REQEUST {
    set guid [findstr [HTTP::query] "docid=" 6 &]
    
    if { $guid ne "" } {
        HTTP::redirect "http://host.example.com/en/server/$guid"
    }
}

Naturally you should substitute an appropriate name for "host.example.com". This will not redirect if the docid query parameter is not found, and it makes no effort to validate the GUID.

Apologies. I spelled "REQUEST" incorrectly. It should be HTTP_REQUEST.

Also, you need to ensure that an http profile is applied to the same Virtual Server to which you will apply this iRule.

Apologies. I spelled "REQUEST" incorrectly. It should be HTTP_REQUEST.

Also, you need to ensure that an http profile is applied to the same Virtual Server to which you will apply this iRule.

The URI fragment above is either malformed, or the request URI was structured in an odd. Query parameters start with a question mark (?). The fragment above is, well, a fragment, because after the path, there is a hash (). This is certainly legal, but it means that everything following the hash () are not query parameters. If I substitute a question mark for the hash, this is what I get:

curl -D - 'http://10.11.210.100:8080/en/server/GUID-876D26ED-3B49-41EB-8470-78D3F60F1360?addHistory=true&filename=GUID-BB7DFC3D-E215-4252-AAFA-29EC2AEA5357.xml&docid=GUID-BB7DFC3D-E215-4252-AAFA-29EC2AEA5357&inner_id=&tid=&query=&scope=&resource=&eventType=lcContent.loadDocGUID-BB7DFC3D-E215-4252-AAFA-29EC2AEA5357'

HTTP/1.0 302 Found
Location: http://host.example.com/en/server/GUID-BB7DFC3D-E215-4252-AAFA-29EC2AEA5357
Server: BigIP
Connection: Keep-Alive
Content-Length: 0

Does the client really send the fragment marker () rather than the query marker (?)?

The URI fragment above is either malformed, or the request URI was structured in an odd. Query parameters start with a question mark (?). The fragment above is, well, a fragment, because after the path, there is a hash (). This is certainly legal, but it means that everything following the hash () are not query parameters. If I substitute a question mark for the hash, this is what I get:

curl -D - 'http://10.11.210.100:8080/en/server/GUID-876D26ED-3B49-41EB-8470-78D3F60F1360?addHistory=true&filename=GUID-BB7DFC3D-E215-4252-AAFA-29EC2AEA5357.xml&docid=GUID-BB7DFC3D-E215-4252-AAFA-29EC2AEA5357&inner_id=&tid=&query=&scope=&resource=&eventType=lcContent.loadDocGUID-BB7DFC3D-E215-4252-AAFA-29EC2AEA5357'

HTTP/1.0 302 Found
Location: http://host.example.com/en/server/GUID-BB7DFC3D-E215-4252-AAFA-29EC2AEA5357
Server: BigIP
Connection: Keep-Alive
Content-Length: 0

Does the client really send the fragment marker () rather than the query marker (?)?

And actually, I lied. The unencoded hash is NOT legal in the submitted URI path. See RFC 3986 section 3.5:

Fragment identifiers have a special role in information retrieval
systems as the primary form of client-side indirect referencing,
allowing an author to specifically identify aspects of an existing
resource that are only indirectly provided by the resource owner.  As
such, the fragment identifier is not used in the scheme-specific
processing of a URI; instead, the fragment identifier is separated
from the rest of the URI prior to a dereference, and thus the
identifying information within the fragment itself is dereferenced
solely by the user agent, regardless of the URI scheme.

In other words, the user-agent is supposed to strip everything from the URI path starting with the hash, and use it for object internal dereferencing (as happens, for example, in an HTML document with the use of

understood as the uri is generated by an application I have no control over it. :(

: /LiveLibrary/web/content.xql?c=t&pub=server-v2&lang=en&action=topic&format=html&docid=GUID-BB7DFC3D-E215-4252-AAFA-29EC2AEA5357&filename=&query=&scope=&tid=

: GUID-BB7DFC3D-E215-4252-AAFA-29EC2AEA5357

: redirecting to http://livelibrarytest.osisoft.int/LiveLibrary/content/en/server-v2/GUID-BB7DFC3D-E215-4252-AAFA-29EC2AEA5357

Sorry, I posted the previous comment then saw your follow-up. Unfortunately, the URI you provide isn't really legal, and the

HTTP::

when CLIENT_ACCEPTED {
    TCP::collect
}

when CLIENT_DATA {
    set guid [findstr [TCP::payload] "docid=" 6 &]
    TCP::release
}

when HTTP_REQUEST {
    if { [info exists guid] && $guid ne "" } {
        HTTP::redirect "http://host.example.com/en/server/$guid"
    }
}

This assumes the entire request URI can be found in the first TCP segment. If you want it to be more robust, you'll have to expand on the logic a bit.

Vernon,

I want to thank you for all your help on this. Unfortunately the docid= is not part of the TCP segment. Going to put this to rest and revisit it later.