Allowing to set the content-type header for direct responses

In the Routes options of the load-balancer, setting up a Direct Response route makes that response returned with a content-type header set to "text/plain". That makes the web browser show the HTML code of the page instead of the web page.


Prompting the user with one tiny extra drop-down menu to set the content-type of the direct response they’re setting up would be very helpful, especially when their origin server have issues that they’re trying to compensate for leveraging F5XC.

  • Étienne Labaume
  • Dec 14 2023
  • Attach files
  • Dane Watson commented
    23 Feb 17:04

    Support & Glen Willms provided the following, for anyone that needs an urgent fix...

    This can be achieved by creating a custom route object. Custom routes are under multi-cloud app connect.

    Here's a sample custom route definition, based on the example documentation

    {
    "metadata": {
    "name": "customroute-blocked",
    "labels": {},
    "annotations": {},
    "disable": false
    },
    "spec": {
    "routes": [
    {
    "match": [
    {
    "http_method": "GET",
    "path": {
    "prefix": "/blocked"
    },
    "query_params": [],
    "headers": [],
    "incoming_port": {
    "no_port_match": {}
    }
    }
    ],
    "route_direct_response": {
    "response_code": 200,
    "response_body": "<html><head><title>Error Page</title></head> \n<body>You are blocked by service policy</body></html>",
    "response_body_encoded": "string:///PGh0bWw+PGhlYWQ+PHRpdGxlPkVycm9yIFBhZ2U8L3RpdGxlPjwvaGVhZD4gCjxib2R5PllvdSBhcmUgYmxvY2tlZCBieSBzZXJ2aWNlIHBvbGljeTwvYm9keT48L2h0bWw+"
    },
    "disable_location_add": false,
    "service_policy": {
    "disable": false
    },
    "waf_type": {
    "inherit_waf": {}
    },
    "inherited_waf_exclusion": {},
    "request_headers_to_add": [],
    "request_headers_to_remove": [],
    "response_headers_to_add": [
    {
    "name": "Content-Type",
    "value": "text/html",
    "append": false
    }
    ],
    "response_headers_to_remove": [],
    "request_cookies_to_add": [],
    "request_cookies_to_remove": [],
    "response_cookies_to_add": [],
    "response_cookies_to_remove": [],
    "disable_custom_script": false,
    "inherited_bot_defense_javascript_injection": {},
    "skip_lb_override": false
    }
    ]
    }
    }


  • Dane Watson commented
    22 Feb 08:52

    I tried copy and pasting json over from a simple route for adding response_headers_to_add like Chris suggested, I cannot get it to work.

    The documentation says it can be text or html, I cannot get it to serve html with the content-type of html. I've tested firefox, chrome and edge, all show the raw html. The documentation shows it working in curl - perhaps this is just a huge miss in product/QA? https://my.f5.com/manage/s/article/K000148053

    Either way, I will attempt to get some traction on this issue. I feel like there must be a known workaround because even tho this issue has been reported multiple times its never been fixed.

  • Chris Triner commented
    November 13, 2024 04:09

    I have worked around this by inserting a response header of 'Content-Type: text/html' in the route which takes precedence over the default header of text/plain

  • Alex Tijhuis commented
    May 28, 2024 14:06

    We've had a customer during the training course, who was asking the exact same thing. Just the option to replace/update the content-type header should be sufficient.

    The WAF blocking page (in XC) is already doing this correctly, so copying the behaviour from there might be an option? If possible, this would really improve the usability of the Direct Response option.