403/404 pages: drupal_get_http_header('Status') returns no status code at all

I can confirm the issue.

I had a bit of a look and it seems to me that maybe there is still work to be done in bootstrap.inc in relation the drupal_http* functions. For example the headers are sent using: Symfony\Component\HttpFoundation::sendHeaders() and not drupal_send_http_headers() which is why they're not available to drupal_get_http_header().

I notice from stepping through the code that you can subscribe to the kernel.terminate event and get the event which has a response object which contains the headers that were sent.

I'd need some direction at this point to get any further towards a solution.

drupal_get_http_header() should be treated as deprecated. All HTTP information is being centralized on the Request/Response objects. If anything, the work here would be to add a @deprecated tag to drupal-get_http_header(), or simply eliminate it entirely (preferable).

I can't tell from a 155 KB patch what you're missing. :-) Can you clarify what it is you're trying to accomplish? (High business level.)

... So you need to inject one bit of HTML into the header for a 200, and a different bit for 404? Hm. Not sure there. I will ping the SCOTCH folks, as Sam may have a thought about it. We're trying to eliminate hook_page_alter, too.

I also have this use case in contrib. Would be interesting to find out what the solution is.

soooo...there are really two levels at which this discussion can be had - one is just the "get it done," and the other is the "understand it, and get it done right." and, there's the way it works in core, vs. how it works in SCOTCH/princess. after a bit of stepping through (omg response exception handling is HILARIOUS - not), i think i have most of these answers on hand...but this is spitball pseudocode.

there are two essential issues here: a) how do i know what the response code is for the current request and b) how do i inject html onto the page output. and the "good samaritan" issue is c) how do i do these things without totally breaking the ability to externally predict what's on the page - though as long as there's no user-specific information that's generated, being a good samaritan is largely a non-issue here.

first, the dirty approach for core.

to figure out what the response code is going to be, you need to go peering through the information that gets placed onto the Request object. this is because of {giant, unnecessary explanation of how response exception handling & subrequesting works}. with how core works right now, the safe place to do that is in an event listener on the KernelEvents::CONTROLLER event. that code should something like this:

class FigureOutTheStatusCode implements EventSubscriberInterface {
  public function onKernelController(FilterControllerEvent $event) {
    $request = $event->getRequest();
    if ($request->attributes->get('exception') instanceof FlattenException) {
      $code = $request->attributes->get('exception')->getStatusCode();
      if (in_array($code, array(403, 404)) {
        set_some_global_with_status_code_for_retrieval_during_hook_page_alter($code);
      }
    }
  }
}

that'll set a global var for you that you can grab later, during hook_page_alter(), to switch on. now, it'd be ideal to avoid hook_page_alter() entirely, but unfortunately you don't have much choice...in core. you could experiment with something that implements a KernelEvents::RESPONSE listener that does some string injection, but with the way HtmlPageController works right now, i think that would only work for the non-200 case, not the normal case.

in SCOTCH/princess, however, this works differently - most notably, because there is no hook_page_alter(). the rule there is, if you want to generate any kind of output (including adding an asset like a javascript file, or javascript settings) you HAVE to be a block. so, you implement some blocks. GA could either implement a few different blocks - a block for a 403, a block for a 404, or just a single block that varies its output based on configuration - and then attach instances of these blocks to the displays that are used specifically for the respective type of responses. for the redirect case, it's basically the same, except that you'd only attach your block to the 404 display. this'll be pretty easy to do programatically - you grab the display used for each of these purposes back, call a method to add your block, save the display, and you're done. like, done-done - no black magic detection of the status code from an exception buried on response object generated by a subrequest that's come out of a catch statement to handle when the original request threw one. yikes. we'll take care of getting that display where it needs to be.

Sam, would there be any sense in encapsulating the head tag contents in their own object somehow before we render the page? Then we could have some alter-like behavior just for those...

This sounds a bit complex to me. I've seen this event driven model, but it looks a wrong way to me. Why is there no variable or array that contains all headers?

because globals are terrible, and having them and relying on them is the best way of chaining our code to the ground, when it wants to fly free...!

if you want access to the sort of globalish data you're looking for, you have to access it at the right time, in the right way. respecting that encapsulation lets us do magical things elsewhere. so, you implement an event - which is roughly like a hook, though does take a bit more setup.

Sam, would there be any sense in encapsulating the head tag contents in their own object somehow before we render the page? Then we could have some alter-like behavior just for those...

sure. that's basically what an HtmlFragment is. so if not that, then a render array.

we don't really have access to that right now because the page element - what drupal_render_page() uses - has #theme_wrapper => 'html'. so you can't really directly access the stuff that's output through the outer html template - you have to manipulate it indirectly via the handful of globals that are read by the rendering process.

though, the HTML head tag is orthogonal to the issue of the HTTP response code header.

The changes brought by #2068471: Normalize Controller/View-listener behavior with a Page object will address this issue; once that goes in you can use a view listener to inject meta tags into the page after the page is rendered, with knowledge of what the status code is.

#2068471: Normalize Controller/View-listener behavior with a Page object is in now, so the status code is available on the HtmlPage object in a view listener. That's where you should detect it and then set the meta tags you need.

The API for setting the metatags on the page object got removed, but hopefully it will be back later. For now, you're stuck with the now-deprecated drupal_add_html_head(). Sorry. :-/

HTTP headers don't exist until the Response object, which doesn't exist until after we're done with the HtmlPage object. Also, at this point hook_page_alter should be viewed as vestigial and non-functional. I don't even know what's going through it at this point, at what level of granularity, and it's almost certain to change again soon. Really, don't use it.

What HTTP header do you need for modifying the HTML? I'm fairly certain whatever goal you're trying to get at can be done, just in a different way than before.

I'm wondering if Redirect's ability to add a local task on 404 pages to create a new redirect has now officially been hosed. It sounds like it.

I think we are planning to leave hook_menu_local_tasks and hook_menu_local_tasks_alter (or at least the latter) in the API so that modules can still dynamically add tabs to any page.

However we must be able to find a way to allow add/get headers anywhere.

No. The "do anything anywhere" model is what was most broken in earlier versions of Drupal. Providing structure around that is the most important improvement of Drupal 8.

For what you describe, you can now add a view listener and check for an HtmlPage object. It has the status code on it (there's a method). If it's 404 (or whatever), you can concat additional Javascript to the end of the page (inside the body tag) by just appending to the content of the object. $page->setContent($page->getContent() . $your_stuff).

If you want to add metatags or links there, that was the goal but that got pulled out. I need to open a new issue to resolve that. For the moment, you still have to use the deprecated drupal_add_*() functions there. Working on that...

@pwolanin: Better question is when hose hooks run, do we know the status code is available? It sounds like in this issue it is later since drupal_get_http_header('Status') doesn't work for hook_page_alter(), then it likely won't work for hook_menu_local_tasks_alter().

A similar feature to the Redirect one is hiding blocks on 404 pages (which we no longer do in core but presumably there's a contrib that does).

@Crell this isn't about 'doing anything anywhere', it's about having the response code available as context during the page rendering process. Which is completely reasonable since we have to know if we're on a 404/403 page before we can build the page array anyway.

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Controlle...

If we make the default 404/403 controller a route instead of hard-coded render array inside that method, then there should be a couple of ways to do this:

1. Check the $request object for _exception_statuscode or make that available as a new public property.

2. Check if the current route is equal to \Drupal::config('system.site')->get('page.404'));

It looks like you could already do that check in hook_page_alter() (or any other place during rendering) if you also checked for the default markup, which ought to be enough of a workaround to unblock the porting.

PS. This is why I thought the method in the other issue is scope creep and asked for it to be removed, it's answering the wrong question.

hass: #2218117: Bring back metatag support for the HtmlPage object

HtmlPage already has the status code on it. Once we bring back the ability to add meta tags/links/etc. on it, you can register a view listener that checks the status code and adds whatever is appropriate.

#2245767: Allow blocks to be configured to show/hide on 200/403/404 response pages and the system help block use $request->attributes->get('exception'). Would something like this:

if ($exception = $request->attributes->get('exception')) {
  debug($exception->getStatusCode());
}

work for your module?

@Crell that issue doesn't solve the actual issue here, which ought to be very fixable.

The response type is known before the 404/403 controller gets executed - otherwise we'd not be able to execute the controller. So the information should be available somewhere.

@hass I already replied in #26 with two options, looks like #30 is a better version of one of them.

That is a good question. With current hook_page_alter(&$page), can't see any other way than $request = \Drupal::request().

We also still have this in MenuTree:

    if ($route_name = $request->attributes->get(RouteObjectInterface::ROUTE_NAME)) {
      // @todo https://drupal.org/node/2068471 is adding support so we can tell
      // if this is called on a 404/403 page.
      $system_path = $request->attributes->get('_system_path');
      $page_not_403 = 1;
    }

But that should now refer to this issue probably.

It seems perhaps that we can use this?

$page_is_403 = $request->attributes->get('_exception_statuscode') == 403;

The functions in question here are all going away, so this is no longer relevant.