-
Notifications
You must be signed in to change notification settings - Fork 20
Handle redirections before creating HTML response #8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
src/PhpDebugBarMiddleware.php
Outdated
*/ | ||
private function isRedirectResponse(ResponseInterface $response) | ||
{ | ||
return $response instanceof RedirectResponse; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will be working with Zend Diactoros, however we need to remember that's psr-7 implementation and someone can use other library. I prefere to check location
header in response object
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, my first implementation was based on httpStatusCode 301 and 302 values. Since this repository depends on diactoros via composer.json and there are less-common status codes exists like 303, 304 etc.. i decided to check instance type. What you think about diactoros dependency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will add diactoros dependency and then? What if someone use eg https://github.com/guzzle/psr7 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean that middleware already depends on diactoros anyway I got the point, diactoros based redirection check would break other psr implementations. I'll send a patch shortly.
@edigu thanks for pr, can u also provide unit test? |
I just add another commit which doesn't depends |
*/ | ||
private function isRedirect(ResponseInterface $response) | ||
{ | ||
return in_array($response->getStatusCode(), [301, 302, 303, 307, 308]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if I send 301 without Location
header?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about that. Debugbar may just return it. RFC says:
The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
IMHO producing a 301 response without a location header would a bad response for other layers too like nginx/apache and browsers. I think this is developer's responsibility.
I think little about it and what about stay with return html as is now, and add link from |
I'm trying to understand why phpdebugbar (a toolbar for development purposes) generates a new template for developer/app? I mean: $template = '<html><head>%s</head><body><h1>DebugBar</h1><p>Response:</p><pre>%s</pre>%s</body></html>'; I have also 404/50X handlers and RedirectResponse instances for redirects. Every time in my app's workflow, phpdebugbar interrupts my app by dumping that template because it can't inject the debugbar head body etc.. IMHO if a middleware doesn't know how to handle a response, it should directly return it AS IS instead of trying to generate a new one. |
This template is generate when you return something else than html (json or xml) |
Since json and xml are just data formats (I mean no HTML markup exists in the response) debugbar may stop there (i think creating a new HtmlResponse instance is the main problem here) or try to inject already collected metrics (params, queries, timinigs etc) into the response in an acceptable manner something like: {
"status" : 200,
"data" : { },
"debugbar" : {
"timing" : {}
"pdo" : {},
"doctrine" : {},
"environment": {}
}
} or <?xml version="1.0" encoding="UTF-8"?>
<data>
<foo />
</data>
<debugbar>
<timing />
</debugbar>
</xml> maybe. I'm still not sure which one is better way to go. Returning the response AS IS sounds like simpler. |
I think we need to make this toolbar more flexible, because we cannot fits all need using one implementation. So attaching should be abstraction, I will do it. In my opinion current implementation, if it's breaks redirect flow, it should still do it, but we can add some location information to generated html. In v2 I will make it more flexible to create own attach implementation, ok? |
@snapshotpl When will this be fixed? I can't use redirects in my application while this middleware is active. 😞 |
Any news on this? |
IMHO debugbar should definitely check the response to make sure it is suitable to injecting more code into it. For e.g.:
Then I would inject the debugbar only after make sure that the response is applicable. |
@edigu I know that's many ways (or cases) when you want to disable or enable debugbar. That's why I pushed #21 . Now you will be able to force enable or disable debugbar three ways.
Then response will be wrapped json/xml response as html response.
Not every 3xx you want to redirect - sometimes you want to debug application before redirect.
Don't see problem here. Same like 2xx or 5xx so debug bar can be attached
Can be fixed by new "force" feature
To text/html debugbar will be attached. With text/plain will work like json/xml |
Fixed in #21 |
I'm trying-out the phpdebugbar for a several days, it does the job nearly perfect. Thank you for your effort.
This PR aims to fix a silly behaviour which occurs when
$outReponse
is aZend\Diactoros\Response\RedirectResponse
instance.I have a zend-expressive application which redirects users to another locations after login/logout like specific actions by returning a
RedirectResponse
instance to outer middleware. The problem is debugbar checks html content-type header to decide the response has HTML or not:When the response doesn't have that header (like
RedirectResponse
case) debugbar creates a newHtmlResponse()
and returns it which completely breaks my app's redirect flow.P.s. My IDE applied some common coding standards via php-cs-fixer after save the file automatically. I can rollback them if you don't like.