Forbidden instead of Unauthenticated while using X-Requested-With with MellonEnable=Auth

[astik]

Hi, In the documentation it said for MellonEnable "Auth":

        #           There is a special handling of AJAX requests, that are
        #           identified by the "X-Requested-With: XMLHttpRequest" HTTP
        #           header. Since no user interaction can happen there,
        #           we always fail unauthenticated (not logged in) requests
        #           with a 403 Forbidden error without redirecting to the IdP.

Looking at the code in auth_mellon_handler.c:

        if(session == NULL || !session->logged_in) {
            /* We don't have a valid session. */

            // ...

            /*
             * If this is an AJAX request, we cannot proceed to the IdP,
             * Just fail early to save our resources
             */
            ajax_header = apr_table_get(r->headers_in, "X-Requested-With");
            if (ajax_header != NULL &&
                strcmp(ajax_header, "XMLHttpRequest") == 0) {
                    AM_LOG_RERROR(APLOG_MARK, APLOG_INFO, 0, r,
                      "Deny unauthenticated X-Requested-With XMLHttpRequest "
                      "(AJAX) request");
                    return HTTP_FORBIDDEN;
            }

My problem comes from HTTP_FORBIDDEN. As far as i understand, if we reach the test for X-Requested-With header, it means we don't have a valid session, it means we are not authenticated. AFAIK there is a semantic issue as forbidden means that we are authenticated still we can't go further. We should have a 401 status code and not a 403. Having a 403 status code while being not authenticated is not good as it is difficult to split between real 403 (authorized but not allowed) and fake 403 (unauthorized).

For what i can tell, changing the return HTTP_FORBIDDEN to something like return HTTP_UNAUTHORIZED should do (still i have no idea where those constants are coming from, my days as a C developer are long gone =D)

[astik]

To go further, in addition to the 401 / 403 returned code, having the URL for the login page would be great in a response header. That way the application that triggered the XHR request earlier could catches the 401/403, could analyses that it will need to redirect the user to a login page defined by the response header. The frontend would be totally agnostic of the middleware configuration which would be the only one to hold configuration of the auth server.