Question:
Why might logged in users suddenly get a 404 error?
Answer:
There are two possible scenarios.
In the first scenario, some users or workstations have the issue but not others and the 404 error occur when trying to open Windows Integrated functions such as BFA, SOV or the Add Files tool. In this case, the user is in the native IE or EDGE browser, but cookies exist that make sfPMS think that our Office Integrated browser (sfDash) is in use. See KBA-01645 for a workaround. Trashing cookies might help.
The second scenario has become less common in recent years and likely only applies to older IIS servers. If the 404 error seems to occur for certain documents and request (often web service requests) consistently, but other documents are just fine, then the ‘problem‘ may be IIS 7 request limits. Check the full 404 error code.
- 404.10 – request header too long
- 404.13 – request content too large
- 404.14 – request URL too long
- 404.15 – request query string too long
In INETMGR, look for Request Filtering in the IIS group within the Features View for the Spitfire Web Application virtual root. (Each application by default inherits from its parent site and parent server). Double-click to open Request Filtering, then in the actions pane click on Edit Feature Settings.
Check the Request content length; Spitfire recommends a value in the range 33554432 to 89128960. (32-85MB).
The value in IIS should match the value in ICTool, SFPMS Misc Options Tab, Maximum Request Size. You can change the value using INETMGR, but ICTool will overwrite your change the next time the site is published.
Additional Comments:
See http://www.iis.net/ConfigReference/system.webServer/security/requestFiltering/requestLimits
KBA-01453; Last updated: September 18, 2017 at 11:39 am;
Keywords: 404 errors