Feature - Add content type to ErrorPage

[LLIT]

To be able to return a JSON error page if creating an API.

I have made a manual insert in the function: Show-PodeErrorPage

$content = Get-PodeFileContentUsingViewEngine -Path $errPagePath -Data @{
        'Url' = ($WebEvent.Protocol + '://' + $WebEvent.Endpoint + $WebEvent.Path);
        'Status' = @{
            'Code' = $Code;
            'Description' = $Description;
        };
        'Exception' = $ex;
        'ContentType' = $WebEvent.Request.ContentType;
    }

And in the default error page i detect it to return HTML/JSON

[Badgerati]

@LLIT , I like it!

When you've had this running, does it format/return all right with the next call being html -Value $content? Just wondering, as that call would set the response content type to be text/html 🤔

Wondering if there could be a way of calling the appropriate response function (json, xml, or html) - or just assume for the error pages that the response type should be the same as the request (with html as default)

[LLIT]

I did some tests, and my Rest client worked, but from Powershell it sucks!
Tested in Powershell 5.1 & 6 Core with disappointing results.
I just get a 404 error in PS 5.1, and no matter how i tried in PS 6 Core, it returned the HTML error page, and not the JSON.

I will do some more testing...

[Badgerati]

Yeah, it'd be dependant on the client sending in the content type on the request.

One thought I had was what if we had multiple file types, and pode selects the appropriate one depending on the request's content type - similar to yours and switching out the content in a single file, though this way you'd know which content type you were getting back for the response (to prevent HTML being sent as JSON because of the request's content type).

Ie, Invoke-WebRequest http:localhost:8080/test -ContentType 'application/json' fails and looks for a 500.json.pode error page first, and if found gets the content and sends back as JSON; otherwise tries 500.pode and sends it back as HTML (regardless of the request's content type being JSON).

🤔

[Badgerati]

@LLIT

Managed to do some work and ideas on this one; so the idea here is like my previous comment, and the error message returned is based on the content-type supplied in the request's headers (with the default being HTML).

For example, if you want to return a JSON error page for a REST API, then the Content-Type header on the request will need to be application/json, and you'll also need a default.json.pode (or <code>.json.pode) file in your /errors directory - if there's no content type, then the HTML error page will be used.

It could also be possible to do this, and your idea too. Possibly through some config setting on errorPages, and making it always return as the request's content type - so you only need a single custom error page - not many (though it'll make the page's content a little complex).

Doing this has given me an idea though: maybe having a "default" content type that could be defined in the pode.json file - so if json was set, then when a request has no Content-Type header supplied then JSON will always be assumed. 🤔

[Badgerati]

Update on this one, the default logic is to use HTML pages.

Similar to the content type overriding, you can set a default content type to use for all error pages in the pode.json. Using the following, you can use 404.json[.pode], default.json[.pode], or just 404.pode or default.pode - the latter two will have the json content type supplied in $data.ContentType:

{
    "web": {
        "errorPages": {
            "default": "application/json"
        }
     }
}

Or you can enable strict content types, which will cause Pode to attempt to generate error page as the same content type in the request (or enforced by the route):

{
    "web": {
        "errorPages": {
            "strictContentTyping": true
        }
     }
}

Or, again like setting up route content types, you can define route patterns for certain content types to use on certain routes when generating the error page:

{
    "web": {
        "errorPages": {
            "routes": {
                "/api/*": "text/xml"
            }
        }
     }
}

You can also set a specific error page content type against routes directly, using the -ErrorType parameter. And, if you use the status function directly, you can supply a -ContentType there as well.