[JIRA] Created: (MAGNOLIA-2936) Error pages not served properly
|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
 |
[JIRA] Created: (MAGNOLIA-2936) Error pages not served properly
by JIRA (on behalf of Hudson CI server)
::
Rate this Message:
Error pages not served properly ------------------------------- Key: MAGNOLIA-2936 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2936 Project: Magnolia Issue Type: Bug Components: cache Affects Versions: 4.2-beta1 Reporter: Grégory Joseph Assignee: Grégory Joseph Fix For: 4.2 If a user tries to access a page which is protected by content-security-filter (as opposed to uri-security-filter, which is located before the cache and gzip filters), the error page is simply not served. This is fairly obvious when looking at the code: {code} if (statusCode != HttpServletResponse.SC_OK) { return; } {code} This links back to MAGNOLIA-2178, but * commenting that bit out seems to work fine (tried Safari 3.0.4, 3.2.1, 4.0.3, Firefox 3.0.4), I can't seem the reproduce the problems of MAGNOLIA-2178 * I'm trying to see what changes could have made this work/fail before, but I can't quite see it right now. Given the current code of GZipFilter, *if* there was indeed an incompatibility between error pages headers and the fact these pages are gzipped, we could anyway easily serve those non-zipped. (it wasn't that trivial when GZipFilter was wrapping the response's output with a GZipOutputStream) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <dev-list-unsubscribe@...> ---------------------------------------------------------------- |
|
|
[JIRA] Commented: (MAGNOLIA-2936) Error pages not served properly
by JIRA (on behalf of Hudson CI server)
::
Rate this Message:
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24840#action_24840 ] Jan Haderka commented on MAGNOLIA-2936: --------------------------------------- AFAIK the problem here is with the errors that come not from magnolia but from the underlying server infrastructure. In case of Magnolia related errors, the response is not committed even after setting the error header, but if it is the Tomcat who gets the error, it will commit the original response because it keeps reference to it and doesn't access the wrapped response that {{GZipFilter}} swapped for the original. To reproduce the issue, that the above code snippet is trying to prevent, just execute request like {{http://localhost:8080/magnoliaAuthor/someDummyPage}} ... if you were not authenticated upfront, the {{statusCode}} will be {{304}} (and response will not be committed) and the login page appear in the browser, however upon hitting the "Login" button, request goes through the whole chain this time, and not being Magnolia page, the {{statusCode}} is set to {{404}}, and when the piece of code above is executed, *the response is already committed*. If the further processing is not abandoned at this point, the attempt to set the gzip encoding header will fail, as shown for example at http://paste.debian.net/51266 and the user gets the {{500}} error instead. ... took me while to figure that out again ... there might be gaps in the "why" this happens, but the "how" should be correct. In any case, the scenario described above can be used to verify the case when code in question is not executed. > Error pages not served properly > ------------------------------- > > Key: MAGNOLIA-2936 > URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2936 > Project: Magnolia > Issue Type: Bug > Components: cache > Affects Versions: 4.2-beta1 > Reporter: Grégory Joseph > Assignee: Grégory Joseph > Fix For: 4.2 > > > If a user tries to access a page which is protected by content-security-filter (as opposed to uri-security-filter, which is located before the cache and gzip filters), the error page is simply not served. This is fairly obvious when looking at the code: > {code} > if (statusCode != HttpServletResponse.SC_OK) { > return; > } > {code} > This links back to MAGNOLIA-2178, but > * commenting that bit out seems to work fine (tried Safari 3.0.4, 3.2.1, 4.0.3, Firefox 3.0.4), I can't seem the reproduce the problems of MAGNOLIA-2178 > * I'm trying to see what changes could have made this work/fail before, but I can't quite see it right now. > Given the current code of GZipFilter, *if* there was indeed an incompatibility between error pages headers and the fact these pages are gzipped, we could anyway easily serve those non-zipped. (it wasn't that trivial when GZipFilter was wrapping the response's output with a GZipOutputStream) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <dev-list-unsubscribe@...> ---------------------------------------------------------------- |
|
|
[JIRA] Issue Comment Edited: (MAGNOLIA-2936) Error pages not served properly
by JIRA (on behalf of Hudson CI server)
::
Rate this Message:
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24840#action_24840 ] Jan Haderka edited comment on MAGNOLIA-2936 at 11/11/09 11:47 AM: ------------------------------------------------------------------ AFAIK the problem here is with the errors that come not from magnolia but from the underlying server infrastructure. In case of Magnolia related errors, the response is not committed even after setting the error header, but if it is the Tomcat who gets the error, it will commit the original response because it keeps reference to it and doesn't access the wrapped response that {{GZipFilter}} swapped for the original. To reproduce the issue, that the above code snippet is trying to prevent, just execute request like {{http://localhost:8080/magnoliaAuthor/someDummyPage}} ... if you were not authenticated upfront, the {{statusCode}} will be {{304}} (and response will not be committed) and the login page appear in the browser, however upon hitting the "Login" button, request goes through the whole chain this time, and not being Magnolia page, the {{statusCode}} is set to {{404}} (by tomcat I believe), and when the piece of code above is executed, *the response is already committed*. If the further processing is not abandoned at this point, the attempt to set the gzip encoding header will fail, as shown for example at http://paste.debian.net/51266 and the user gets the {{500}} error instead. ... took me while to figure that out again ... there might be gaps in the "why" this happens, but the "how" should be correct. In any case, the scenario described above can be used to verify the case when code in question is not executed. was (Author: had): AFAIK the problem here is with the errors that come not from magnolia but from the underlying server infrastructure. In case of Magnolia related errors, the response is not committed even after setting the error header, but if it is the Tomcat who gets the error, it will commit the original response because it keeps reference to it and doesn't access the wrapped response that {{GZipFilter}} swapped for the original. To reproduce the issue, that the above code snippet is trying to prevent, just execute request like {{http://localhost:8080/magnoliaAuthor/someDummyPage}} ... if you were not authenticated upfront, the {{statusCode}} will be {{304}} (and response will not be committed) and the login page appear in the browser, however upon hitting the "Login" button, request goes through the whole chain this time, and not being Magnolia page, the {{statusCode}} is set to {{404}}, and when the piece of code above is executed, *the response is already committed*. If the further processing is not abandoned at this point, the attempt to set the gzip encoding header will fail, as shown for example at http://paste.debian.net/51266 and the user gets the {{500}} error instead. ... took me while to figure that out again ... there might be gaps in the "why" this happens, but the "how" should be correct. In any case, the scenario described above can be used to verify the case when code in question is not executed. > Error pages not served properly > ------------------------------- > > Key: MAGNOLIA-2936 > URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2936 > Project: Magnolia > Issue Type: Bug > Components: cache > Affects Versions: 4.2-beta1 > Reporter: Grégory Joseph > Assignee: Grégory Joseph > Fix For: 4.2 > > > If a user tries to access a page which is protected by content-security-filter (as opposed to uri-security-filter, which is located before the cache and gzip filters), the error page is simply not served. This is fairly obvious when looking at the code: > {code} > if (statusCode != HttpServletResponse.SC_OK) { > return; > } > {code} > This links back to MAGNOLIA-2178, but > * commenting that bit out seems to work fine (tried Safari 3.0.4, 3.2.1, 4.0.3, Firefox 3.0.4), I can't seem the reproduce the problems of MAGNOLIA-2178 > * I'm trying to see what changes could have made this work/fail before, but I can't quite see it right now. > Given the current code of GZipFilter, *if* there was indeed an incompatibility between error pages headers and the fact these pages are gzipped, we could anyway easily serve those non-zipped. (it wasn't that trivial when GZipFilter was wrapping the response's output with a GZipOutputStream) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <dev-list-unsubscribe@...> ---------------------------------------------------------------- |
|
|
[JIRA] Commented: (MAGNOLIA-2936) Error pages not served properly
by JIRA (on behalf of Hudson CI server)
::
Rate this Message:
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24842#action_24842 ] Grégory Joseph commented on MAGNOLIA-2936: ------------------------------------------ The piece of code mentioned above is also necessary for redirects > Error pages not served properly > ------------------------------- > > Key: MAGNOLIA-2936 > URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2936 > Project: Magnolia > Issue Type: Bug > Components: cache > Affects Versions: 4.2-beta1 > Reporter: Grégory Joseph > Assignee: Grégory Joseph > Fix For: 4.2 > > > If a user tries to access a page which is protected by content-security-filter (as opposed to uri-security-filter, which is located before the cache and gzip filters), the error page is simply not served. This is fairly obvious when looking at the code: > {code} > if (statusCode != HttpServletResponse.SC_OK) { > return; > } > {code} > This links back to MAGNOLIA-2178, but > * commenting that bit out seems to work fine (tried Safari 3.0.4, 3.2.1, 4.0.3, Firefox 3.0.4), I can't seem the reproduce the problems of MAGNOLIA-2178 > * I'm trying to see what changes could have made this work/fail before, but I can't quite see it right now. > Given the current code of GZipFilter, *if* there was indeed an incompatibility between error pages headers and the fact these pages are gzipped, we could anyway easily serve those non-zipped. (it wasn't that trivial when GZipFilter was wrapping the response's output with a GZipOutputStream) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <dev-list-unsubscribe@...> ---------------------------------------------------------------- |
|
|
[JIRA] Updated: (MAGNOLIA-2936) Error pages not served properly
by JIRA (on behalf of Hudson CI server)
::
Rate this Message:
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grégory Joseph updated MAGNOLIA-2936: ------------------------------------- Fix Version/s: 4.2.1 (was: 4.2) > Error pages not served properly > ------------------------------- > > Key: MAGNOLIA-2936 > URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2936 > Project: Magnolia > Issue Type: Bug > Components: cache > Affects Versions: 4.2-beta1 > Reporter: Grégory Joseph > Assignee: Grégory Joseph > Fix For: 4.2.1 > > > If a user tries to access a page which is protected by content-security-filter (as opposed to uri-security-filter, which is located before the cache and gzip filters), the error page is simply not served. This is fairly obvious when looking at the code: > {code} > if (statusCode != HttpServletResponse.SC_OK) { > return; > } > {code} > This links back to MAGNOLIA-2178, but > * commenting that bit out seems to work fine (tried Safari 3.0.4, 3.2.1, 4.0.3, Firefox 3.0.4), I can't seem the reproduce the problems of MAGNOLIA-2178 > * I'm trying to see what changes could have made this work/fail before, but I can't quite see it right now. > Given the current code of GZipFilter, *if* there was indeed an incompatibility between error pages headers and the fact these pages are gzipped, we could anyway easily serve those non-zipped. (it wasn't that trivial when GZipFilter was wrapping the response's output with a GZipOutputStream) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <dev-list-unsubscribe@...> ---------------------------------------------------------------- |
|
|
[JIRA] Commented: (MAGNOLIA-2936) Error pages not served properly
by JIRA (on behalf of Hudson CI server)
::
Rate this Message:
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24925#action_24925 ] Grégory Joseph commented on MAGNOLIA-2936: ------------------------------------------ One of the inline comments says: //return on error or redirect code, because response is already committed But as far as I can tell, it's not. For instance in case of 404 and the contents ({{flat}} byte array stream) is actually empty at that point (since Magnolia doesn't generate it) Another thing that might be related or not: the {{CacheResponseWrapper}} does not implement {{containsHeader}} and probably should. I haven't committed this, since I'm not sure how it should do this: {code} public boolean containsHeader(String name) { return super.containsHeader(name) || headers.containsKey(name); // or return headers.containsKey(name); } {code} (probably the former, since headers might have been prior to this wrapper) > Error pages not served properly > ------------------------------- > > Key: MAGNOLIA-2936 > URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2936 > Project: Magnolia > Issue Type: Bug > Components: cache > Affects Versions: 4.2-beta1 > Reporter: Grégory Joseph > Assignee: Grégory Joseph > Fix For: 4.2.1 > > > If a user tries to access a page which is protected by content-security-filter (as opposed to uri-security-filter, which is located before the cache and gzip filters), the error page is simply not served. This is fairly obvious when looking at the code: > {code} > if (statusCode != HttpServletResponse.SC_OK) { > return; > } > {code} > This links back to MAGNOLIA-2178, but > * commenting that bit out seems to work fine (tried Safari 3.0.4, 3.2.1, 4.0.3, Firefox 3.0.4), I can't seem the reproduce the problems of MAGNOLIA-2178 > * I'm trying to see what changes could have made this work/fail before, but I can't quite see it right now. > Given the current code of GZipFilter, *if* there was indeed an incompatibility between error pages headers and the fact these pages are gzipped, we could anyway easily serve those non-zipped. (it wasn't that trivial when GZipFilter was wrapping the response's output with a GZipOutputStream) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <dev-list-unsubscribe@...> ---------------------------------------------------------------- |
|
|
[JIRA] Commented: (MAGNOLIA-2936) Error pages not served properly
by JIRA (on behalf of Hudson CI server)
::
Rate this Message:
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24934#action_24934 ] Grégory Joseph commented on MAGNOLIA-2936: ------------------------------------------ Also see MAGNOLIA-2472 > Error pages not served properly > ------------------------------- > > Key: MAGNOLIA-2936 > URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2936 > Project: Magnolia > Issue Type: Bug > Components: cache > Affects Versions: 4.2-beta1 > Reporter: Grégory Joseph > Assignee: Grégory Joseph > Fix For: 4.2.1 > > > If a user tries to access a page which is protected by content-security-filter (as opposed to uri-security-filter, which is located before the cache and gzip filters), the error page is simply not served. This is fairly obvious when looking at the code: > {code} > if (statusCode != HttpServletResponse.SC_OK) { > return; > } > {code} > This links back to MAGNOLIA-2178, but > * commenting that bit out seems to work fine (tried Safari 3.0.4, 3.2.1, 4.0.3, Firefox 3.0.4), I can't seem the reproduce the problems of MAGNOLIA-2178 > * I'm trying to see what changes could have made this work/fail before, but I can't quite see it right now. > Given the current code of GZipFilter, *if* there was indeed an incompatibility between error pages headers and the fact these pages are gzipped, we could anyway easily serve those non-zipped. (it wasn't that trivial when GZipFilter was wrapping the response's output with a GZipOutputStream) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <dev-list-unsubscribe@...> ---------------------------------------------------------------- |
|
|
[JIRA] Commented: (MAGNOLIA-2936) Error pages not served properly
by JIRA (on behalf of Hudson CI server)
::
Rate this Message:
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24942#action_24942 ] Jan Haderka commented on MAGNOLIA-2936: --------------------------------------- {quote} But as far as I can tell, it's not. For instance in case of 404 and the contents (flat byte array stream) is actually empty at that point (since Magnolia doesn't generate it) {quote} The call to {{sendError()}} method causes response to be committed (check the spec). Try to run it in debug mode and call {{response.isCommited()}} ... As soon as the request goes through the Magnolia filter chain completely and no content is found and the last thing that is done is letting the request go through to the Tomcat so it can try to serve a static content from the webapp (and it also doesn't find anything), the response will be committed even tho we override the {{sendError()}} methods in the wrapper response. Just re-run the scenario I described above, you'll see that it is really committed at this point. > Error pages not served properly > ------------------------------- > > Key: MAGNOLIA-2936 > URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2936 > Project: Magnolia > Issue Type: Bug > Components: cache > Affects Versions: 4.2-beta1 > Reporter: Grégory Joseph > Assignee: Grégory Joseph > Fix For: 4.2.1 > > > If a user tries to access a page which is protected by content-security-filter (as opposed to uri-security-filter, which is located before the cache and gzip filters), the error page is simply not served. This is fairly obvious when looking at the code: > {code} > if (statusCode != HttpServletResponse.SC_OK) { > return; > } > {code} > This links back to MAGNOLIA-2178, but > * commenting that bit out seems to work fine (tried Safari 3.0.4, 3.2.1, 4.0.3, Firefox 3.0.4), I can't seem the reproduce the problems of MAGNOLIA-2178 > * I'm trying to see what changes could have made this work/fail before, but I can't quite see it right now. > Given the current code of GZipFilter, *if* there was indeed an incompatibility between error pages headers and the fact these pages are gzipped, we could anyway easily serve those non-zipped. (it wasn't that trivial when GZipFilter was wrapping the response's output with a GZipOutputStream) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <dev-list-unsubscribe@...> ---------------------------------------------------------------- |
|
|
[JIRA] Work started: (MAGNOLIA-2936) Error pages not served properly
by JIRA (on behalf of Hudson CI server)
::
Rate this Message:
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MAGNOLIA-2936 started by Jan Haderka. > Error pages not served properly > ------------------------------- > > Key: MAGNOLIA-2936 > URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2936 > Project: Magnolia > Issue Type: Bug > Components: cache > Reporter: Grégory Joseph > Assignee: Jan Haderka > Fix For: 4.2.x > > > If a user tries to access a page which is protected by content-security-filter (as opposed to uri-security-filter, which is located before the cache and gzip filters), the error page is simply not served. This is fairly obvious when looking at the code: > {code} > if (statusCode != HttpServletResponse.SC_OK) { > return; > } > {code} > This links back to MAGNOLIA-2178, but > * commenting that bit out seems to work fine (tried Safari 3.0.4, 3.2.1, 4.0.3, Firefox 3.0.4), I can't seem the reproduce the problems of MAGNOLIA-2178 > * I'm trying to see what changes could have made this work/fail before, but I can't quite see it right now. > Given the current code of GZipFilter, *if* there was indeed an incompatibility between error pages headers and the fact these pages are gzipped, we could anyway easily serve those non-zipped. (it wasn't that trivial when GZipFilter was wrapping the response's output with a GZipOutputStream) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <dev-list-unsubscribe@...> ---------------------------------------------------------------- |
|
|
[JIRA] Assigned: (MAGNOLIA-2936) Error pages not served properly
by JIRA (on behalf of Hudson CI server)
::
Rate this Message:
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Haderka reassigned MAGNOLIA-2936: ------------------------------------- Assignee: Jan Haderka (was: Grégory Joseph) > Error pages not served properly > ------------------------------- > > Key: MAGNOLIA-2936 > URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2936 > Project: Magnolia > Issue Type: Bug > Components: cache > Reporter: Grégory Joseph > Assignee: Jan Haderka > Fix For: 4.2.x > > > If a user tries to access a page which is protected by content-security-filter (as opposed to uri-security-filter, which is located before the cache and gzip filters), the error page is simply not served. This is fairly obvious when looking at the code: > {code} > if (statusCode != HttpServletResponse.SC_OK) { > return; > } > {code} > This links back to MAGNOLIA-2178, but > * commenting that bit out seems to work fine (tried Safari 3.0.4, 3.2.1, 4.0.3, Firefox 3.0.4), I can't seem the reproduce the problems of MAGNOLIA-2178 > * I'm trying to see what changes could have made this work/fail before, but I can't quite see it right now. > Given the current code of GZipFilter, *if* there was indeed an incompatibility between error pages headers and the fact these pages are gzipped, we could anyway easily serve those non-zipped. (it wasn't that trivial when GZipFilter was wrapping the response's output with a GZipOutputStream) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <dev-list-unsubscribe@...> ---------------------------------------------------------------- |
|
|
[JIRA] Commented: (MAGNOLIA-2936) Error pages not served properly
by JIRA (on behalf of Hudson CI server)
::
Rate this Message:
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25433#action_25433 ] Hudson CI server commented on MAGNOLIA-2936: -------------------------------------------- Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif! [magnolia_main-trunk #1146|http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1146/] MAGNOLIA-2968, - make sure content of the buffer is written to the output stream and flushed (but without writing gzip headers) even on error. > Error pages not served properly > ------------------------------- > > Key: MAGNOLIA-2936 > URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2936 > Project: Magnolia > Issue Type: Bug > Components: cache > Reporter: Grégory Joseph > Assignee: Jan Haderka > Fix For: 4.2.x > > > If a user tries to access a page which is protected by content-security-filter (as opposed to uri-security-filter, which is located before the cache and gzip filters), the error page is simply not served. This is fairly obvious when looking at the code: > {code} > if (statusCode != HttpServletResponse.SC_OK) { > return; > } > {code} > This links back to MAGNOLIA-2178, but > * commenting that bit out seems to work fine (tried Safari 3.0.4, 3.2.1, 4.0.3, Firefox 3.0.4), I can't seem the reproduce the problems of MAGNOLIA-2178 > * I'm trying to see what changes could have made this work/fail before, but I can't quite see it right now. > Given the current code of GZipFilter, *if* there was indeed an incompatibility between error pages headers and the fact these pages are gzipped, we could anyway easily serve those non-zipped. (it wasn't that trivial when GZipFilter was wrapping the response's output with a GZipOutputStream) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <dev-list-unsubscribe@...> ---------------------------------------------------------------- |
|
|
[JIRA] Updated: (MAGNOLIA-2936) Error pages not served properly
by JIRA (on behalf of Hudson CI server)
::
Rate this Message:
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Bärfuss updated MAGNOLIA-2936: -------------------------------------- Fix Version/s: 4.2.2 (was: 4.2.x) > Error pages not served properly > ------------------------------- > > Key: MAGNOLIA-2936 > URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2936 > Project: Magnolia > Issue Type: Bug > Components: cache > Reporter: Grégory Joseph > Assignee: Jan Haderka > Fix For: 4.2.2 > > > If a user tries to access a page which is protected by content-security-filter (as opposed to uri-security-filter, which is located before the cache and gzip filters), the error page is simply not served. This is fairly obvious when looking at the code: > {code} > if (statusCode != HttpServletResponse.SC_OK) { > return; > } > {code} > This links back to MAGNOLIA-2178, but > * commenting that bit out seems to work fine (tried Safari 3.0.4, 3.2.1, 4.0.3, Firefox 3.0.4), I can't seem the reproduce the problems of MAGNOLIA-2178 > * I'm trying to see what changes could have made this work/fail before, but I can't quite see it right now. > Given the current code of GZipFilter, *if* there was indeed an incompatibility between error pages headers and the fact these pages are gzipped, we could anyway easily serve those non-zipped. (it wasn't that trivial when GZipFilter was wrapping the response's output with a GZipOutputStream) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <dev-list-unsubscribe@...> ---------------------------------------------------------------- |
|
|
[JIRA] Resolved: (MAGNOLIA-2936) Error pages not served properly
by JIRA (on behalf of Hudson CI server)
::
Rate this Message:
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Haderka resolved MAGNOLIA-2936. ----------------------------------- Resolution: Fixed > Error pages not served properly > ------------------------------- > > Key: MAGNOLIA-2936 > URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2936 > Project: Magnolia > Issue Type: Bug > Components: cache > Reporter: Grégory Joseph > Assignee: Jan Haderka > Fix For: 4.2.2 > > > If a user tries to access a page which is protected by content-security-filter (as opposed to uri-security-filter, which is located before the cache and gzip filters), the error page is simply not served. This is fairly obvious when looking at the code: > {code} > if (statusCode != HttpServletResponse.SC_OK) { > return; > } > {code} > This links back to MAGNOLIA-2178, but > * commenting that bit out seems to work fine (tried Safari 3.0.4, 3.2.1, 4.0.3, Firefox 3.0.4), I can't seem the reproduce the problems of MAGNOLIA-2178 > * I'm trying to see what changes could have made this work/fail before, but I can't quite see it right now. > Given the current code of GZipFilter, *if* there was indeed an incompatibility between error pages headers and the fact these pages are gzipped, we could anyway easily serve those non-zipped. (it wasn't that trivial when GZipFilter was wrapping the response's output with a GZipOutputStream) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <dev-list-unsubscribe@...> ---------------------------------------------------------------- |
| Free embeddable forum powered by Nabble | Forum Help |
