[Solved] Getting 302 redirect to Login Page when trying to upload file on Telerik.Web.UI.WebResource.axd endpoint

[joh]

Hey all!

I'm currently testing our production system at our lab, version of Telerik UI is 2012.2.607.40.
When trying to upload file using the Telerik.Web.UI.WebResource.axd?type=rau  endpoint, I'm getting a 302 status code redirect to our app's login page.
What is wrong here? 

Thanks all,
john

[Rumen]

Hi John,

Please note that version 2012.2.607.40 is pretty old and vulnerable to critical vulnerabilities like CVE-2019-18935, that is why it is strongly recommended to upgrade to the latest version of Telerik UI for ASP.NET AJAX.

As for the reported error: A 302 redirect to your application's login page when accessing the Telerik.Web.UI.WebResource.axd?type=rau endpoint usually means that authentication is required, but the handler request is not being authenticated properly. This prevents RadAsyncUpload from uploading files.

Here are the main causes and steps to resolve the issue:

1. Authentication Restrictions on Handler

• Your authentication setup (e.g., Forms Authentication, Windows Authentication, or a reverse proxy like WebSEAL) may be blocking unauthenticated requests to the .axd handler.
• RadAsyncUpload requires that the handler is accessible to process uploads.

How to Fix:

• Allow access to Telerik.Web.UI.WebResource.axd by updating your web.config file. For example, with Forms Authentication, add:

  <location path="Telerik.Web.UI.WebResource.axd">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>
  

• If you use a reverse proxy (such as WebSEAL), ensure the handler path is correctly mapped and accessible.

2. Incorrect Handler Path

• If the handler path is missing a folder or is not correct (for example, /Telerik.Web.UI.WebResource.axd instead of /control/Telerik.Web.UI.WebResource.axd), the upload will fail and may trigger a redirect.
• Check the path generated in the page source and compare it to the actual handler location.

How to Fix:

• Set the correct handler path using the HttpHandlerUrl property:

  <telerik:RadAsyncUpload ID="RadAsyncUpload1" runat="server" HttpHandlerUrl="~/control/Telerik.Web.UI.WebResource.axd" />

3. Test Handler Accessibility

• Try browsing directly to:

  http://yourdomain/control/Telerik.Web.UI.WebResource.axd?type=rau
  

  If configured correctly, you should see:

  { "message" : "RadAsyncUpload handler is registered successfully, however, it may not be accessed directly." }
  

• If you are redirected to the login page, authentication or path configuration is still blocking access.

 

Useful Resources:

• http://docs.telerik.com/devtools/aspnet-ajax/general-information/troubleshooting/web-resources-troubleshooting
• http://docs.telerik.com/devtools/aspnet-ajax/controls/asyncupload/security#recommended-settings

 

Regards,
Rumen
Progress Telerik

[joh]

Hey Rumen!

Users can access /Telerik.Web.UI.WebResource.axd?type=rau unauthenticated (POST/GET).
But when trying to upload file using RadAsyncUpload, I get a 302 redirect.
I played with our website a bit, and saw that when removing the filename attribute from this line in the POST request:

FROM:
Content-Disposition: form-data; name="file"; filename="MyProfilePicture.jpeg"
TO:
Content-Disposition: form-data; name="file";

I get 200:
{ "message" : "RadAsyncUpload handler is registered succesfully, however, it may not be accessed directly." }

But file is not being uploaded.
What is wrong with our configuration?


Thanks

[Rumen]

Hi John,

Thank you for the additional details - this is actually a very revealing clue. Looking at the RadAsyncUpload handler source, the reason removing filename gives you a 200 is straightforward: when no file is attached, context.Request.Files.Count == 0 and the handler immediately returns the diagnostic registration message without running any upload logic. The 302 you see with a file attached means something upstream in the IIS pipeline is intercepting the request before the handler code is ever reached - this is not a Telerik configuration issue per se, but an infrastructure one.

Why the filename Attribute Makes the Difference

• Without filename, the request has no attached file (Request.Files.Count == 0). The handler returns the registration message and exits early - no security layer flags it.
• With filename present, the request is a real multipart file upload. A WAF, reverse proxy, authentication module, or IIS rule sees it differently and redirects it.
• The redirect happens before the handler processes anything, which is why the Telerik configuration itself is not the root cause.

Most Likely Causes and Steps to Resolve

1. Web Application Firewall (WAF) or Reverse Proxy

• If your system sits behind a WAF, load balancer, or reverse proxy (e.g., F5, AWS WAF, Cloudflare, WebSEAL, ModSecurity), it may be configured to intercept multipart requests containing file uploads and enforce its own authentication rules triggered specifically by the Content-Disposition: filename field.
• Check with your infrastructure/network team whether any such device is inspecting upload traffic on that header attribute.
• Try testing the upload directly from the server itself (localhost) to bypass any external proxy. If uploads work from localhost but not externally, the issue is in the network path, not the application.

2. IIS Request Filtering

• IIS may be blocking file extensions or rejecting requests that exceed content length limits. Ensure your web.config permits uploads:
  

  <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxAllowedContentLength="31457280" /> <!-- 30 MB -->
        <fileExtensions allowUnlisted="true" />
      </requestFiltering>
    </security>
  </system.webServer>
  
  <system.web>
    <httpRuntime maxRequestLength="31072" /> <!-- in KB, ~30 MB -->
  </system.web>

3. Custom HTTP Modules or Global.asax

• Check web.config for any custom <httpModules> / <modules> entries.
• Review Global.asax for code in Application_BeginRequest or Application_AuthenticateRequest that might inspect Content-Type: multipart/form-data requests and enforce a redirect.

4. Handler Registration and Path

• Verify the handler is registered in both <system.web> and <system.webServer> sections of your web.config.
• If the handler path is incorrect (e.g., missing a subfolder prefix), set it explicitly:

  <telerik:RadAsyncUpload ID="RadAsyncUpload1" runat="server"
      HttpHandlerUrl="~/Telerik.Web.UI.WebResource.axd" />

• Also check for nested web.config files in subfolders that could override authorization or handler settings.

5. Antivirus / Endpoint Protection

• Server-side antivirus products (e.g., Symantec Endpoint Protection, Trend Micro) sometimes intercept HTTP file upload streams and issue redirects when they trigger on the file content or the filename field. Try temporarily disabling on-access scanning for the upload temp folder as a diagnostic step.

How to Diagnose Quickly

1. Inspect the 302 response headers using Fiddler or browser DevTools. The Location header in the redirect will reveal which component is issuing it (your app's own login page URL, a WAF login page, a proxy URL, etc.).
2. Test from localhost — if uploads work directly on the server but not externally, the issue is in the network path (WAF/proxy).
3. Enable IIS Failed Request Tracing (FREB) for 302 status codes on the handler path. This will show exactly which IIS module in the pipeline is issuing the redirect.

Critical: Upgrade Your Version

As mentioned previously, version 2012.2.607.40 is critically vulnerable to CVE-2019-18935 and other known exploits targeting the async upload handler. We strongly recommend upgrading to the latest version and applying the recommended security settings.

Summary: The 302 is issued before the Telerik handler runs — something in your IIS pipeline or network infrastructure intercepts multipart POST requests with a filename and redirects them. The FREB logs and the Location header of the redirect are your fastest path to identifying exactly which layer is responsible.

Regards,
Rumen
Progress Telerik

Regards,
Rumen
Progress Telerik