Here is the setup: migrating a page that takes an encrypted string from a query string and processes it to redirect to the wanted page.
The problem: The querystring is too long (8760) and the result goes to a page not found but if I truncate the encrypted string it to a much shorter length (2035 or less), it goes through, but of course it does not process)
More info: I have so far added in the keys
<httpRuntime targetFramework="4.6.1" maxRequestLength="2097151" waitChangeNotification="1" maxWaitChangeNotification="3600" requestValidationMode="2.0" maxQueryStringLength="32768" maxUrlLength="65536" enable="true"/>
I am at a loss, and can only think there is some sort of hidden setting that I am missing but cannot figure it out.
The sample URL I am useing (to give you an idea of the length is:
http://localhost:1112/SSO/Consume?SAMLResponse=PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIENvbnNlbnQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpjb25zZW50OnVuc3BlY2lmaWVkIiBEZXN0aW5hdGlvbj0iaHR0cHM6Ly93ZWxsdG9rLnF1aXRsb2dpeC5vcmcvU1NPL0NvbnN1bWUuYXNweCIgSUQ9Il9kNjllMDk4ZjNjZDMzMWRkY2M0MGU2NmRhMzE5MDBhMiIgSXNzdWVJbnN0YW50PSIyMDIwLTEwLTIyVDIzOjU5OjQwWiIgVmVyc2lvbj0iMi4wIj48SXNzdWVyIHhtbG5zPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIj5odHRwczovL2NhZmV3ZWxsLmNvbTwvSXNzdWVyPjxzYW1scDpTdGF0dXM+PHNhbWxwOlN0YXR1c0NvZGUgVmFsdWU9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpzdGF0dXM6U3VjY2VzcyIvPjwvc2FtbHA6U3RhdHVzPjxzYW1sOkFzc2VydGlvbiB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIiBJRD0iXzViOTNhZTQ3ZDNiYzJhYjRkNDY5YjEzNWViODE0ZjUxIiBJc3N1ZUluc3RhbnQ9IjIwMjAtMTAtMjJUMjM6NTk6NDBaIiBWZXJzaW9uPSIyLjAiPjxzYW1sOklzc3Vlcj5odHRwczovL2NhZmV3ZWxsLmNvbTwvc2FtbDpJc3N1ZXI+PGRzOlNpZ25hdHVyZSB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+PGRzOlNpZ25lZEluZm8geG1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiPjxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIj48L2RzOkNhbm9uaWNhbGl6YXRpb25NZXRob2Q+PGRzOlNpZ25hdHVyZU1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNyc2Etc2hhMSI+PC9kczpTaWduYXR1cmVNZXRob2Q+PGRzOlJlZmVyZW5jZSBVUkk9IiNfNWI5M2FlNDdkM2JjMmFiNGQ0NjliMTM1ZWI4MTRmNTEiPjxkczpUcmFuc2Zvcm1zPjxkczpUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjZW52ZWxvcGVkLXNpZ25hdHVyZSI+PC9kczpUcmFuc2Zvcm0+PGRzOlRyYW5zZm9ybSBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMTAveG1sLWV4Yy1jMTRuIyI+PC9kczpUcmFuc2Zvcm0+PC9kczpUcmFuc2Zvcm1zPjxkczpEaWdlc3RNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjc2hhMSI+PC9kczpEaWdlc3RNZXRob2Q+PGRzOkRpZ2VzdFZhbHVlPmtNUWdSanR4TDZqVUdrN3NoRGJ3MUFuMFZRTT08L2RzOkRpZ2VzdFZhbHVlPjwvZHM6UmVmZXJlbmNlPjwvZHM6U2lnbmVkSW5mbz48ZHM6U2lnbmF0dXJlVmFsdWU+WEZJMHFkSjNVWXpCS0VETFR2Y3VXbjhCcnEzY3Izc0p5T3lBZGZsN2J5K0IrSnN2OVpYeTRFQ0tIaUlVSVV2K2RJRHFwaDNDc3o1OUdQcFZnekdNcmNVNFFlYmlnYlhMVm92TkNUQVY1dFlWQWI2TnlSbFp5cW9qRld3dEZMdFhqUzZva1ZmYTFkelJSSXZGSnJTTjVYQS85WVNNTXRaQlhsSlVCelpYaEdVdVlyOFZJNGh3aWpBaWpUNDdzQm9Wbk85b2taNUJ2cXYrMXZZaFVGZEJINktPaEc0d0lIbXEwOForSTZ3L0V3Z3V2MThYdk9pbUhidkkvWTV3NkJTb0owNnl6cGZxR0lXVmZ3MVBnTjNwdGJpZE9icGdId0VtS0pqNFdlVk9ZOGQwUk4xazN6Mk5LQitqQzFmakZvT3hFd2FQQTlhd0U0RDNiSmc1UXZaSGRzQTBwVmFLazQxODJQK0hGR0FyUUdYZVcvNnNraTVHVVhYc2tOTXFUTDZnZG9iNWYreHVoc3VjTmx2TjltT3ZzR1NFR3lLVzZ3U3BQVkJrQko4SE44ZWZ0a2FBRFVQOFJWaGdFZ3pmenlibHRRNlVqMEZRbS9wZkJFV1FQRGl5dm5Ia25CRVlab2E5TDZvRnZTL2lNQURXSjNNZk40MHV4NUVCSVdmdWp4ZzhBZjhjYi9qSEpucTF5S1JPQ0ZXM2drOGNaNmdFazZNZ1dySDVYSCtFWmx6YjZ0Ym5KdEZTOVdIa1Fic1pCdkpXRzhrSUEwOUM5T3FzUmdBemVub2lUK0k0U0UvTURBcFRNcE0vREJITm5qNVZYeFR0LzU1V1cyQWtUWU1hWWQwckY3NFNvbDRCZUpGL0ZlL2dMdm8wMXBLWDN4U3BTUlphbTdJRWNHSkM2T1E9PC9kczpTaWduYXR1cmVWYWx1ZT48S2V5SW5mbyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+PGRzOlg1MDlEYXRhPjxkczpYNTA5Q2VydGlmaWNhdGU+TUlJSVp6Q0NCMCtnQXdJQkFnSVFDODBLZGRMd0MvVURLK2VodWtoWUNqQU5CZ2txaGtpRzl3MEJBUXNGQURCd01Rc3dDUVlEVlFRR0V3SlZVekVWTUJNR0ExVUVDaE1NUkdsbmFVTmxjblFnU1c1ak1Sa3dGd1lEVlFRTEV4QjNkM2N1WkdsbmFXTmxjblF1WTI5dE1TOHdMUVlEVlFRREV5WkVhV2RwUTJWeWRDQlRTRUV5SUVocFoyZ2dRWE56ZFhKaGJtTmxJRk5sY25abGNpQkRRVEFlRncweU1EQXpNRFF3TURBd01EQmFGdzB5TWpBMk1EY3dNREF3TURCYU1HSXhDekFKQmdOVkJBWVRBbFZUTVJFd0R3WURWUVFJRXdoRGIyeHZjbUZrYnpFUE1BMEdBMVVFQnhNR1JHVnVkbVZ5TVJZd0ZBWURWUVFLRXcxWFpXeHNkRzlyTENCSmJtTXVNUmN3RlFZRFZRUUREQTRxTG1OaFptVjNaV3hzTG1OdmJUQ0NBaUl3RFFZSktvWklodmNOQVFFQkJRQURnZ0lQQURDQ0Fnb0NnZ0lCQU1HSFpyOSs5R0w5Vy9ZYjRoL2E0OGJMUU9KVzRySFpJcjhHYVVwRFZabEtrS2laeHcvVWZVUVc1RFNkU0hTWGRaYVRVZ0xUejA2ekhza1JHd0l3cW5ENXp4M0hjT1YyRVdhRCtITGFhTjRBMkJVU0JHQzBkUjdJZHg2eXFFeXp0YWc3S3k2TFhSNlVqbHJqSjA4NDJlVVNud0YrTnNWcWNBSG4yMzJlOGZENno0QTFwN2o4T1NkRmxiOEJmdjFmRVgzeFQwZGNBQmdrZ0orL1Zzdm56anZPWmZRQStxL1BPZVpwNWN3TE1Ed2daWWtiNUFIbUJxMEVXUHR2RmtHci9iNW1LdXVvcUxmeTlzbVR2NHJ2SlJ0dDJOMW5RRTZ6dnlLMjlzVUx6S0xzZEE5aEhvY0krVmJqTms0T3RxMzBSek1MeUN2K0c4V2VzK1dOSFZEcm1VOVpmTUU0STFCNzBKK0pSaEN4VDhZK28vK0lZVHlVdWFJeGNXZEtpSFNKWVFEaTlrRTkydGZhWVZtWWg5Rk9XUUpCTklyRFMwVXV0cFkvc2FtcS8wcDM3bHhwSkpGUXlycGlveVIwc1NEL0FqaXlHS3pCSHpRQWt2T0VHaE1obTBtUDJWazc2UEhZWmpHKzVMM2RQWVNQcXRGYnE5bDI4dStncWwvVjNXdzRVUmxBbnNHL0ZHcDhBVitLQ05uVWRtVEtjSzhBQ2xmTm1FdjRTTW5SL3hhdDdXaDVtUUc2a3NDUEVJZkxRV0d3MEFIT2ZQTkF3SVlSRFNsT1pzNDMrTTlWTW0xV3p3MzBWNFJFbjdsY1hqbWhNdXlKbnlXWW1za0VKMEFBdC9FRXRrdGNCMEZUeG13bk9VTE5SRGFjRmpDWE15ZHFZU2k2QUhPejhiUWZUcUxIQWdNQkFBR2pnZ1FKTUlJRUJUQWZCZ05WSFNNRUdEQVdnQlJSYVArUXJ3SUhkVHpNMldWa1lxSVN1Rmx5T3pBZEJnTlZIUTRFRmdRVUN0K3JFMmxyTHhZU0pUQ2ZWRkFUNEdlQ3JKSXdQd1lEVlIwUkJEZ3dOb0lPS2k1allXWmxkMlZzYkM1amIyMkNER05oWm1WM1pXeHNMbU52YllJV1pHVnBjeTF3Y205a0xtTmhabVYzWld4c0xtTnZiVEFPQmdOVkhROEJBZjhFQkFNQ0JhQXdIUVlEVlIwbEJCWXdGQVlJS3dZQkJRVUhBd0VHQ0NzR0FRVUZCd01DTUhVR0ExVWRId1J1TUd3d05LQXlvRENHTG1oMGRIQTZMeTlqY213ekxtUnBaMmxqWlhKMExtTnZiUzl6YUdFeUxXaGhMWE5sY25abGNpMW5OaTVqY213d05LQXlvRENHTG1oMGRIQTZMeTlqY213MExtUnBaMmxqWlhKMExtTnZiUzl6YUdFeUxXaGhMWE5sY25abGNpMW5OaTVqY213d1RBWURWUjBnQkVVd1F6QTNCZ2xnaGtnQmh2MXNBUUV3S2pBb0JnZ3JCZ0VGQlFjQ0FSWWNhSFIwY0hNNkx5OTNkM2N1WkdsbmFXTmxjblF1WTI5dEwwTlFVekFJQmdabmdRd0JBZ0l3Z1lNR0NDc0dBUVVGQndFQkJIY3dkVEFrQmdnckJnRUZCUWN3QVlZWWFIUjBjRG92TDI5amMzQXVaR2xuYVdObGNuUXVZMjl0TUUwR0NDc0dBUVVGQnpBQ2hrRm9kSFJ3T2k4dlkyRmpaWEowY3k1a2FXZHBZMlZ5ZEM1amIyMHZSR2xuYVVObGNuUlRTRUV5U0dsbmFFRnpjM1Z5WVc1alpWTmxjblpsY2tOQkxtTnlkREFNQmdOVkhSTUJBZjhFQWpBQU1JSUIrQVlLS3dZQkJBSFdlUUlFQWdTQ0FlZ0VnZ0hrQWVJQWR3QXBlYjd3bmprNUlmQldjNTlqcFhmbHZsZDluR0FLK1BsTlhTWmNKVjNIaEFBQUFYQ21HK2FjQUFBRUF3QklNRVlDSVFDSUtFTGFLc1lFMExJeXlZS2VrQTZteEd2OVFkZytOWHNGckp3Uk9iVUxaUUloQU5aRmh6R01Fb2pVdnZoOW0rYUkxRGZFb0QrZmxBZWJBNE96TXgvMXhobjhBSFlBSWtWRkIxbFZKRmFXUDZFdjhmZHRodUFqSm1PdHdFdC9YY2FEWEc3aUR3SUFBQUZ3cGh2bTl3QUFCQU1BUnpCRkFpQVljTFlaRGR6M0xNTC9URHNKYnNQeUgxRlNVbE5WdlhJOGpVVkdldDVxR3dJaEFJV1NsYlJIVXZKMEVNank5UlMyQkFsWVI4VWxqWkJIcGRtd3ZyV1MvbkFWQUhjQXBMa0prTFFZV0JTSHV4T2l6R2R3Q2p3MW1BVDVHOSs0NDNmTkRzZ04zQkFBQUFGd3Bodm1uZ0FBQkFNQVNEQkdBaUVBeVFKdDhLRmtKSmU4R3JXc0ZRV2pqTXo1aFpPMkMzdjJpQkU3VjRWTW5Pb0NJUUNidmpIM2huOGNkdnJyNklzbE5XTmhpQ3lLekdjL1NtdmY5cnJNMndIbFNnQjJBRUhJeXJIZklrWktFTWFoT2dsQ2gxNU9NWXNiQSt2clM4ZG84SkJpbGdiMkFBQUJjS1liNXBzQUFBUURBRWN3UlFJaEFNZmF3T2lhQjRjYk5FRmNlUE5pRW00VzBpdmh4ZXZTS1AweHBzOWpLZ0UzQWlCNWtLbFA1MXd0VmJEVWxnaGxKNVpHemFsYlJ3cXlSclpWSEFmaTMvOFVLVEFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBWEMyUmhUMm52NVVEQ3ZYclhNMjU1Rk5iNkoxYjNGNDZlMW14bkhDNFNMcTZvLzVhZVhhMmpvS0pqK0ZzSlNaZ2dJQkJFNy9aalVqZ3MxbnFxS056SlM5cVFiaEQ3ZnArWER6MFdrcUM3Q3ZlTmQ5Q2p3cHhSYUNsRUc2U3Z6eU1xaUtoMWVEWXpyNmUremVhVkFJUHlwejh0WnBjQTJKd1A3dUthcDkzMHpYc0VkaUZqV0hEL0U4dlVBQS9aYnYrNHk3Y09BUnBSTk5NTk5laE9FMGVpMVBhb1JYUU9yYVBQVThaVy96SlpCRWl0OVJlZncwU3RTMTRZcFM3UWRHM25obGdwQzhlS1hWOXcxT3IyaVNVZC9kK0hxWW5BVWZDWENpeEhMSTBidUF2d3p5V0Y2djZ4aXlqV2xwdmlKSjB2YitzYk5xempvWnFudUFwcDhlSjhBPT08L2RzOlg1MDlDZXJ0aWZpY2F0ZT48L2RzOlg1MDlEYXRhPjwvS2V5SW5mbz48L2RzOlNpZ25hdHVyZT48c2FtbDpTdWJqZWN0PjxzYW1sOk5hbWVJRCBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjEuMTpuYW1laWQtZm9ybWF0OnVuc3BlY2lmaWVkIj4wZjAyMjZhMy1hYmM3LTRjNjItOTQyYi1mMTA3YzA0Zjc5MmQ8L3NhbWw6TmFtZUlEPjxzYW1sOlN1YmplY3RDb25maXJtYXRpb24gTWV0aG9kPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6Y206YmVhcmVyIj48c2FtbDpTdWJqZWN0Q29uZmlybWF0aW9uRGF0YSBOb3RPbk9yQWZ0ZXI9IjIwMjAtMTAtMjNUMDA6MDI6NDBaIiBSZWNpcGllbnQ9Imh0dHBzOi8vd2VsbHRvay5xdWl0bG9naXgub3JnL1NTTy9Db25zdW1lLmFzcHgiPjwvc2FtbDpTdWJqZWN0Q29uZmlybWF0aW9uRGF0YT48L3NhbWw6U3ViamVjdENvbmZpcm1hdGlvbj48L3NhbWw6U3ViamVjdD48c2FtbDpDb25kaXRpb25zIE5vdEJlZm9yZT0iMjAyMC0xMC0yMlQyMzo1OTozNVoiIE5vdE9uT3JBZnRlcj0iMjAyMC0xMC0yM1QwMDo1OTo0MFoiPjxzYW1sOkF1ZGllbmNlUmVzdHJpY3Rpb24+PHNhbWw6QXVkaWVuY2U+PC9zYW1sOkF1ZGllbmNlPjwvc2FtbDpBdWRpZW5jZVJlc3RyaWN0aW9uPjwvc2FtbDpDb25kaXRpb25zPjxzYW1sOkF0dHJpYnV0ZVN0YXRlbWVudD48c2FtbDpBdHRyaWJ1dGUgTmFtZT0iVVVJRCI+PHNhbWw6QXR0cmlidXRlVmFsdWU+MGYwMjI2YTMtYWJjNy00YzYyLTk0MmItZjEwN2MwNGY3OTJkPC9zYW1sOkF0dHJpYnV0ZVZhbHVlPjwvc2FtbDpBdHRyaWJ1dGU+PHNhbWw6QXR0cmlidXRlIE5hbWU9IlJlbGF5U3RhdGUiPjxzYW1sOkF0dHJpYnV0ZVZhbHVlPi9xdWl0L2dvYWxzLmFzcHg8L3NhbWw6QXR0cmlidXRlVmFsdWU+PC9zYW1sOkF0dHJpYnV0ZT48c2FtbDpBdHRyaWJ1dGUgTmFtZT0idXNlcm5hbWUiPjxzYW1sOkF0dHJpYnV0ZVZhbHVlPjEwMDAwNTJfZTwvc2FtbDpBdHRyaWJ1dGVWYWx1ZT48L3NhbWw6QXR0cmlidXRlPjxzYW1sOkF0dHJpYnV0ZSBOYW1lPSJ0YXNrIj48c2FtbDpBdHRyaWJ1dGVWYWx1ZT4zMzcxNmI1Mi0zNzIyLTQxZDctOGExZS1kNzliZDliMWQ1YzY8L3NhbWw6QXR0cmlidXRlVmFsdWU+PC9zYW1sOkF0dHJpYnV0ZT48L3NhbWw6QXR0cmlidXRlU3RhdGVtZW50PjxzYW1sOkF1dGhuU3RhdGVtZW50IEF1dGhuSW5zdGFudD0iMjAyMC0xMC0yMlQyMzo1OTo0MFoiIFNlc3Npb25JbmRleD0iXzViOTNhZTQ3ZDNiYzJhYjRkNDY5YjEzNWViODE0ZjUxIj48c2FtbDpBdXRobkNvbnRleHQ+PHNhbWw6QXV0aG5Db250ZXh0Q2xhc3NSZWY+dXJuOmZlZGVyYXRpb246YXV0aGVudGljYXRpb246d2luZG93czwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj48L3NhbWw6QXV0aG5Db250ZXh0Pjwvc2FtbDpBdXRoblN0YXRlbWVudD48L3NhbWw6QXNzZXJ0aW9uPjwvc2FtbHA6UmVzcG9uc2U+
What browser are you using to test? IE11 has URL length limitations that are shorter than what IIS can handle.
In the tests in the link above, IE11 was able to handle up to "4043" characters in the URL.
It also appears there are 2 places where your update might need to be made.
<configuration>
...
<system.webServer>
...
<security>
<requestFiltering>
<requestLimits maxQueryString="8192" />
</requestFiltering>
</security>
</system.webServer>
</configuration>
and
<configuration>
...
<system.web>
...
<httpRuntime ... maxQueryStringLength="8192" />
</system.web>
</configuration>
In situations where a large amount of data needs sent to an application, like in a SAML request, the request is made as a POST with the data in the request body, rather than as a GET, so they are not subject to URL length limitations.
I also don't think this issue is a Kentico problem, unless you are seeing different results in a new WebForms application project with the same web.config settings.
I could not find the specific answer to this when searching so I'm posting my solution here.
We were working fine with SignalR for a long time, then some users started getting 404 errors on the start and connect calls from AngularJs/jQuery to the server. Negotiate would work fine though and return a 200 code.
It turns out by default the server side (ASP.NET 4.6.1) must impose a limit on the size of a URL and instead of returning a 414 (Request-URI Too Long) like you might expect it must just truncate the URL at a length around 2,083 and still try to process it. I'm assuming the 404 is the SignalR hub responding because now the truncated string has query string parameters that don't match what is expected. We were seeing it because we were passing a couple custom values and the security access token via query string parameters which increased the size. The access token was passed via query string because we wanted to use websockets and headers don't exist for websockets. As you add more attributes and roles to your token it will grow which is what put us over the default size limit.
The fix is easy. Just update your server web.config to allow longer URLs.
<system.web>
<httpRuntime targetFramework="4.5" maxRequestLength="30000000" maxUrlLength="40960" maxQueryStringLength="2097151" />
</system.web>
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="30000000" maxUrl="40960" maxQueryString="2097151" />
</requestFiltering>
</security>
</system.webServer>
I have a service written using servicestack v3.9. I am trying to return a large result set and am getting an 500 internal server error on my client. If I look at the details of the error I see the results are listed in the exception but are truncated after 65536 characters. I know this is a default limit imposed by .net. What I don't know is how to increase it for service stack.
My client isn't connecting to the service using a binding in the web config since it's using service stack. For web api calls this seems like where you would fix this issue be increasing maxReceivedMessageSize in the binding. I am guessing there is some way to increase this limit for service stack too??
ServiceStack doesn't impose any limits or quota's itself, so any limits your Services hit are IIS/ASP.NET's which can be increased the same as any other ASP.NET Web Application.
The Web.Config example configuration below shows how to increase the request limit to 1GB in both IIS6 and IIS7:
<configuration>
<system.web>
<httpRuntime maxRequestLength="1048576" />
</system.web>
</configuration>
For IIS7 and above, you also need to add the lines below:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
</security>
</system.webServer>
I have a WCF service (over a webHttpBinding) using ASP.NET 4/IIS 8 and I had no problems communicating with it using JSON with GET. However, today I needed to implement a method that sends a large query string (about 3000 characters, not that long but longer than that I've been using). I called the service and immediately got a 404 error, without even stepping into my code at my debug machine. The first thing that came to my mind is the maximum query string length limit. I've added this to my web.config:
<system.webServer>
<directoryBrowse enabled="true" />
<security>
<requestFiltering>
<requestLimits maxQueryString="8000"></requestLimits>
</requestFiltering>
</security>
</system.webServer>
Now, I am getting this server error when I call the service: The length of the query string for this request exceeds the configured maxQueryStringLength value. Weird enough, I've tried other values such as 200000, way over my query string and URL, which is about 3000 characters. Am I missing something?
Maybe set maxQueryStringLength in the httpRuntime element.
It's a bit confusing to have two configuration settings, but I believe they can be interpreted as follows:
The httpRuntime maxQueryStringLength property is new to ASP.NET 4 and configures the maximum query string length that can be processed by the ASP.NET HTTP runtime. Prior to ASP.NET 4 this was a hardwired value of 2048; it can now be increased.
The system.web/security/requestFiltering maxQueryStringLength property is an IIS 7 setting and allows an administrator to restrict the maximum query string length. This setting isn't specific to ASP.NET.
I have a file upload control on my webpage. The maximum request length is set to 8 MB (maxRequestLength = 8192). I also have server validation that throws an error if the file is more than 4MB. The reason that its 8MB in the config is the leverage that's given to the user and also so that the application can be tested.
If I upload a file that's 9MB, I get thrown an exception Maximum request length exceeded., which is fine and working as expected. But when I try to upload a file that's 1GB, it shows me a HTTP 404 - File not found. Can someone please explain why this is happening and how can I get it to throw me a maxRequestLength exception?
I'm using IIS6.
I experienced this condition today (HTTP 404 on large file upload with IIS 7) but I thought I had made all the correct configuration settings. I wanted to upload files up to 300MB so I made the following web.config settings in a sub-folder of the application:
<configuration>
<system.web>
<httpRuntime maxRequestLength="307200" />
</system.web>
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="314572800" />
</requestFiltering>
</security>
</system.webServer>
</configuration>
This configuration worked in test but when I copied the updated files including the web.config to the production server, I received the HTTP 404 error on uploading a 90MB file. Smaller files under the application-wide limit of 30MB were working fine, so I knew it was a request size problem of some sort.
I figured there was a chance IIS had cached some application settings and just hadn't updated them, so I recycled the Application Pool, after which everything worked as expected.
I feel none of the answers here explain why you get a 404, they just tell you the usual stuff of how to fix the problem.
The 404 is not due to misconfiguration, it is intentional and documented behaviour:
When request filtering blocks an HTTP request because an HTTP request exceeds the request limits, IIS 7 will return an HTTP 404 error to the client and log one of the following HTTP statuses with a unique substatus that identifies the reason that the request was denied:
HTTP Substatus Description
404.13 Content Length Too Large
404.14 URL Too Long
404.15 Query String Too Long
These substatuses allow Web administrators to analyze their IIS logs and identify potential threats.
In addition, when an HTTP request exceeds the header limits that are defined in the in the <headerLimits> element, IIS 7 will return an HTTP 404 error to the client with the following substatus:
HTTP Substatus Description
404.10 Request Header Too Long
This is a bit of an old thread, but I thought I should add my experiences with this.
I faced the same problem with large file uploads and the web api. A 404.13 is thrown before it gets to a controller at all, so I had to find out where to jump in and handle this case.
My solution was the following web.config entries:
I handle the 404.13 by redirecting it to a mvc controller (it could be a webforms page just the same), and regular 404 errors hit my 404 route. it's critical that the responseMode="redirect" for the 404.13
<httpErrors errorMode="Custom">
<remove statusCode="404" subStatusCode="-1" />
<error statusCode="404" subStatusCode="13" path="/errors/filesize" responseMode="Redirect" />
<error statusCode="404" path="/errors/notfound" responseMode="ExecuteURL" />
</httpErrors>
Then, in my Errors controller, I have the following:
public ActionResult FileSize()
{
Response.StatusCode = 500;
Response.StatusDescription = "Maximum file size exceeded.";
Response.End();
return null;
}
Again, this could be a regular webforms page.
To my knowledge, there is no way to gracefully handle exceeding IIS's "maxRequestLength" setting. It can't even display a custom error page (since there is no corresponding HTTP code to respond to). The only way around this is to set maxRequestLength to some absurdly high number of kbytes, for example 51200 (50MB), and then check the ContentLength after the file has been uploaded (assuming the request didn't time out before 90 seconds). At that point, I can validate if the file <=5MB and display a friendly error.
You can also try this link.
You could also try something like this:
private void application_EndRequest(object sender, EventArgs e)
{
HttpRequest request = HttpContext.Current.Request;
HttpResponse response = HttpContext.Current.Response;
if ((request.HttpMethod == "POST") &&
(response.StatusCode == 404 && response.SubStatusCode == 13))
{
// Clear the response header but do not clear errors and transfer back to requesting page to handle error
response.ClearHeaders();
HttpContext.Current.Server.Transfer(request.AppRelativeCurrentExecutionFilePath);
}
}
I have found that this problem can also be caused on IIS7 (and presumably IIS6) when the URLScan tool is installed and running on the site.
When uploading the file to a website i was receiving the message "File or directory not found. The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable."
If the problem is being caused by URLScan then if you try to upload the large file to the site whilst browsing the site on the hosting server itself, you will be served a full asp.net error message instead of a 404 that mentions URLScan.
You can also check if URLScan is running on you site in IIS7 by viewing the ISAPI Filters for the website in IIS, URLScan will be listed if it is used.
This can be fixed by altering the ini file for URLScan is located at "%WINDIR%\System32\Inetsrv\URLscan" and changing the MaxAllowedContentLength.
The MaxAllowedContentLength is in bytes.
This may require a IIS restart to take effect, though it did not when i tried it myself with IIS7.
http://www.iis.net/learn/extensions/working-with-urlscan/urlscan-overview
http://www.iis.net/learn/extensions/working-with-urlscan/common-urlscan-scenarios
You could configure the default error page in IIS itself.
The request limit is a setting is IIS. Open the Request Filtering section of your site in IIS and select Edit Request Settings. For me it was that simple.
A more detailed How To from Microsoft.
https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/#how-to-edit-the-request-filtering-feature-settings-and-request-limits
I just met the same problem, i made the similar operation like pseudocoder's answer but have different( i think maybe is not the cache) :
edit your Web.config --> maxRequestLength
<system.web>
<httpRuntime maxRequestLength="1073741824" executionTimeout="3600" />
</system.web>
edit this:
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
</security>
just like this,and try it.
The problem with the 1GB uploads is more browser related. I have had heaps of trouble with it and tried a lot of solutions but really the question to ask here is what are the chances of this happening in the real world for your business needs and maybe it should be recorded as a known issue in the business rules or non functional requirements document.