Forum Discussion
NimbostratusFragment Identifiers that ARE sent by browsers
I argued long and hard that browsers should not be sending the Fragment-Identifiers in the HTTP request. But I then I looked at some traces and I see that they sure look like they are sent! I don't know when or why, but browsers in 2015 seem to be sending the "" Fragment Identifiers in the HTTP request. And guess what? Our app devs (and I think Sharepoint) would like to see them.
So, how to look at, analyze, and ultimately forward these FIs in the request? I have an iRule and have logged http::uri and even http::request and the FI has been stripped off when I know that Firefox has indeed made the request with it intact. I used an extension called SAML-Trace to see the HTTP request and response.
We are LTM 11.6.
Trace request: GET test HTTP/1.1
My logged info: Nov 18 11:42:01 george ProxyPass_SecureCookieOnly-D VS=/Common/vs_yadayadayada-443, serverip to Host=yada.yada.yada, URI=/MissionControl/OAT/Meetings/?blahblah: NewRequest REQ="GET /MissionControl/OAT/Meetings/?blahblah HTTP/1.1 Host: yada.yada.yada Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 Accept-Language: en-us Connection: keep-alive Accept-Encoding: gzip, deflate User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/601.2.7 (KHTML, like Gecko) Version/9.0.1 Safari/601.2.7 X-Forwarded-For: client-ip "
1 Reply
- Kevin_Stewart
Employee
Well, for what it's worth, SAML Tracer is a browser plugin, not a proxy. So if you actually did see FIs in SAML Tracer, it's likely only what the browser is seeing locally. If you do an actual packet capture you shouldn't see FIs on the wire, nor would any mainstream browser reliably send them if one was flukishly doing so. In other words, I wouldn't count on using FIs at the server level.
