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>
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>
We have a web service which is denys access to all except a single IP address. This is configured like so
<location path="ASMX/Service.asmx">
<system.webServer>
<security>
<ipSecurity allowUnlisted="false">
<clear />
<add ipAddress="[Our IP address]" allowed="true" />
</ipSecurity>
</security>
</system.webServer>
We recently installed a Web Application Firewall, so now all traffic now comes from a single source. The firewall however collects the origin IP and puts it into a request header called 'X-Origin-IP'.
Is it possible to use the web.config to read this new header and only allow where certain value exists, or is it better to drop into the code and perform the analysis there?
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>