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.
Related
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'm using system.text.utf8encoding.utf8.getstring to convert a byte array to a string and then am sending it to my asp.net program through a regular web request as a POST value. Every now and then, I get an exception
"A potentially dangerous Request.Form value was detected from the
client "
Is it possible to get rid of that?
EDIT: never mind, I started using webclient.uploaddata to send and receiving by request.binaryread instead, this method doesn't seem to have this problem.
try to Add below code put to your web.config file.
<system.web>
<pages validateRequest="false" />
</system.web>
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>
During security review of our asp.net web application we got reported that some input fields doesn't restrict length of user input on server side. There is said in execution report that this vulnerability can be used to consume large amount of resources in the server or database which can cause Denial of Service attacks.
I would like to ask what options are here to fix this. Of course we can implement the validation on web server side for every field and e.g. throw some exception and reject if input is longer then some predefined value. But I am curious if there is some more other ways how to do it. Maybe some configuration in web.config or on IIS server level, some global handler etc.
Check out maxRequestLength setting in web.config.
Specifies the limit for the input stream buffering threshold, in KB. This limit can be used to prevent denial of service attacks that are caused, for example, by users posting large files to the server.
The default is 4096 (4 MB).
<configuration>
<system.web>
<httpRuntime maxRequestLength="1024" />
</system.web>
</configuration>
This would be a better solution than restricting each individual field as it is protecting your application as a whole as it sounds like they haven't found any specific inputs that are vulnerable.
If you want this to only apply to certain sections of your application you could add an override using the <location> element:
<location path="Attachments/Upload">
<system.web>
<httpRuntime maxRequestLength="20480" />
</system.web>
</location>