Unexpected Restart due to IPv6 URL

<< Back to Knowledge Search

Technical Alert

Affected Products

All SGOS versions prior to,, 6.1.4.


It is possible that a ProxySG  enabled for ICAP processing could restart spontaneously when encountering and attempting to process Literal Address IPv6 URLs.

This issue is a result of an error in parsing the bracketed format of the hostname part of an IPv6 URL.

The bracketed syntax is a valid syntax as stated in RFC: 2732.  In the section of the RFC entitled “Format for Literal IPv6 Addresses in URLs”, it is specified that “To use a literal IPv6 address in a URL, the literal address should be enclosed in "[" and "]" characters. 

This results in URLs with a format of http[s]://[host name or host ip]/path

When encountering this URL type and trying to access the file for ICAP transmission, the ProxySG will restart. The signature of the crash dump file (mini-context, context, or full) will be something of the following nature.

PF in HTTP SW BF1E5EC0 for BFB2BEC0" in "ce_admin.dll"

You can look at the crash dump signature in your sysinfo file, by looking at the URL https://<proxy name> or <proxy_ip>:8082/sysinfo.  Search for “Minicontext”.

It may not be immediately obvious that the data stream contains such a URL, since it is likely  served from a server within an HTML response. This also makes it difficult to locate the offending URL except via a packet trace or core dump analysis.

Increased use of IPv6 and of embedding literal IPV6 URLs in web pages will make this issue more likely to occur over time.


Fixed in and higher 5.4 versions.

Fixed in and higher 5.5 versions.

Fixed in 6.1.4 and higher versions.


 Upgrade to a  version that includes the fix.


Disabling ICAP will avoid the situation. This is seldom a viable alternative.

Disabling ICAP for the destination (if known) will avoid the problem, but also may not be viable.

If the destination is known, then a force deny on the destination in a Web Access Layer will avoid the ICAP process. Again, for the same reason as above, this may or may not be viable.

If there is a common part of in the returned URL, then a sub string match may work for a while. At least until the path name changes or another pathnames emerges.

Attempting to match on the brackets in policy will not work.

Bug Number

 148313, 149406, 149404

InQuira Doc IdTFA64

Article Feedback

Hide Properties
First Published      10/01/2014
Last Modified      10/01/2014
Last Published      10/01/2014
Article Audience
Product      ProxySG
Article Number      000007615
Was this helpful?
Previous MonthNext Month