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 encountered a weird case during debugging a WebAPI controller for saving files.
My controller has a method for posting data
[HttpPost]
[HttpPut]
public async Task<HttpResponseMessage> Upload()
{
if (!request.Content.IsMimeMultipartContent())
{
throw new HttpResponseException(HttpStatusCode.UnsupportedMediaType);
}
var provider = await request.Content.ReadAsMultipartAsync();
MultipartFileData file = provider.FileData.FirstOrDefault();
// this is the uploaded file: file.LocalFileName
}
Controller's logic doesn't matter much here. The key point here is that the controller expects multipart-content.
Now from the client where I'm using jquery.fileupload library I send files via POST method.
I set a breakpoint on the first line of the controller's Upload method and send a file from the client. The breakpoint goes off. It goes off before all file were uploaded to the server. It's expected behavior and everything is good.
Now the problem. I send a large file and the breakpoint doesn't go off. The file is being uploaded (POSTed) and the controller isn't being called!
Event worse that after the file is finally uploaded I get 404 Not Found on the client.
My site is on localhost under IIS with ASP.NET Web API 5.1.2 (.NET 4.5).
I start changing file size to choose the size when the things works. It turns out that is't 1000000000 (one million bytes). If a request's length (data and headers) is 1M bytes that everything works: breakpoint goes off and the file is uploaded. If a request's length 1 byte more that nothing works: breakpoint doesn't go off, the file seems to being uploaded (i.e. tha data is sending) but it's unclear where it's uploaded as the controller isn't called.
As my site on localhost I can't believe it's caused by proxy server.
So my question is what is going on? What can be wrong with posting 1M bytes requests?
p.s. I'm aware of IIS and ASP.NET hard limits for request lengths (4Gb and 2Gb) - they are not exceeded.
In IIS Manager click on your site and go Configuration Editor - you will need to alter maxRequestLength to a value that will work with your requirements.
Edit:
The second place request limits are set are here:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1000000000" /> <!-- change this -->
</requestFiltering>
</security>
</system.webServer>
So I completely forgot about settings in web.config. It turns out that 1M was the limit set there :(
<system.web>
<httpRuntime maxRequestLength="1000000000" />
</system.web>
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1000000000" />
</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 WCF end point inside my .NET 4.0 Web Application project. Using the VS2010 WCF Test Client, I can connect to the service correctly. However when I go to use the service I get a generic error message:
The content type text/html; charset=UTF-8 of the response message does not match the content type of the binding (text/xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. The first 1024 bytes of the response were:
When I looked at the requests on IIS Express I got the following:
Request started: POST http://machinename:port/Services/Services.svc
Request started: GET http://machinename:port/Services/Services.svc?AspxAutoDectectCookieSupport=1
Request started: GET http://machinename:port/(X(1)A(LKwosYYszAEkAAAAMDE2YzlmNWItNTZIOS00ZDY1LTgzOTAtNDIxNDgyOWZIYWViJ86TX46muUQoL_psmkZK2rgWbO41))/Services/Services.svc?AspxAutoDectectCookieSupport=1
Request ended: "http://machinename:port/Services/Services.svc" with HTTP status 302.0
Request ended: "http://machinename:port/Services/Services.svc?AspxAutoDectectCookieSupport=1" with HTTP status 302.0
Request ended: "http://machinename:port/Services/Services.svc?AspxAutoDectectCookieSupport=1" with HTTP status 200.0
So it seems like after POSTing to the service it is getting redirected to the standard web page for the service. Yet when I remove:
<authentication mode="Forms">
<forms cookieless="AutoDetect" loginUrl="~/Security/LoginClient.aspx" name="FORMAUTH" />
from the web.config it works. Any ideas what is happening? I have tried to remove the folder the service is in from authentication (http://stackoverflow.com/questions/5593720/authentication-mode-forms-causing-errors-in-wcf-end-point) but the issue still remains.
While this works using the Visual Studio Development Server (Cassini) when I run it through IIS Express 7.5 the same error occurs with or without authentication.
You have to provide authorization for your web services to be contacted anonymously in your web.config:
<location path="MyWebServices">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
This assumes that you keep all of your services in a folder called MyWebServices relative to the root of the application. You have to allow * or it will force a login for access.
I am experiencing the same issue as soon as I use the machinename instead of localhost in the service address. I did try to use a "baseAddressPrefixFilters" but without success.
<serviceHostingEnvironment>
<baseAddressPrefixFilters>
<add prefix="http://XLSiteSampleD.aginsurance.intranet/PIXLSiteSample" />
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
I thought that option could have been to enable the aspNetCompatibility in the web.config
with the related attribute on the service :
[AspNetCompatibilityRequirements(RequirementsMode =
AspNetCompatibilityRequirementsMode.Allowed)]
But is does not the trick either :(
It only works with an address like http://localhost/VirtualSite/MyService.svc without a domain and without the baseAddressPrefixFilters !
V.
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.