March 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11558) Content-Type header is not set in HTTP response for directory resource in servlet directory-listing feature

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/WFLY-11558?page=com.atlassian.jira.plugi... ] Flavia Rainone closed WFLY-11558. --------------------------------- Resolution: Done > Content-Type header is not set in HTTP response for directory resource in servlet directory-listing feature > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-11558 > URL: https://issues.redhat.com/browse/WFLY-11558 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 15.0.0.Final > Reporter: Jan Stourac > Assignee: Stuart Douglas > Priority: Major > Fix For: 16.0.0.Final, 16.0.0.Beta1 > > Attachments: helloworld-html5.war > > > [DefaultServlet|https://github.com/undertow-io/undertow/blob/master/servle...] does not set Content-Type HTTP header in response for the directory resource when directory-listing feature is enabled. > As browsers apparently try to guess appropriate Content-Type of the downloaded resource, this problem is not spotted unless in combination with [X-Content-Type-Options|https://developer.mozilla.org/en-US/docs/Web/HTTP/...] header is present in the HTTP response too. This header effectively discourages browser to guess the Content-Type of the resource. > Output for directory-listing request in attached reproducer [^helloworld-html5.war]: > {code} > $ curl -v http://127.0.0.1:8080/helloworld-html5/css/ >/dev/null > * Trying 127.0.0.1... > * TCP_NODELAY set > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0) > > GET /helloworld-html5/css/ HTTP/1.1 > > Host: 127.0.0.1:8080 > > User-Agent: curl/7.59.0 > > Accept: */* > > > < HTTP/1.1 200 OK > < Connection: keep-alive > < Content-Length: 824 > < Date: Fri, 04 Jan 2019 14:32:46 GMT > < > { [824 bytes data] > 100 824 100 824 0 0 804k 0 --:--:-- --:--:-- --:--:-- 804k > * Connection #0 to host 127.0.0.1 left intact > {code} > Notice that there is no Content-Type header in HTTP response. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11558) Content-Type header is not set in HTTP response for directory resource in servlet directory-listing feature

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/WFLY-11558?page=com.atlassian.jira.plugi... ] Flavia Rainone updated WFLY-11558: ---------------------------------- Fix Version/s: 16.0.0.Final 16.0.0.Beta1 > Content-Type header is not set in HTTP response for directory resource in servlet directory-listing feature > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-11558 > URL: https://issues.redhat.com/browse/WFLY-11558 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 15.0.0.Final > Reporter: Jan Stourac > Assignee: Stuart Douglas > Priority: Major > Fix For: 16.0.0.Beta1, 16.0.0.Final > > Attachments: helloworld-html5.war > > > [DefaultServlet|https://github.com/undertow-io/undertow/blob/master/servle...] does not set Content-Type HTTP header in response for the directory resource when directory-listing feature is enabled. > As browsers apparently try to guess appropriate Content-Type of the downloaded resource, this problem is not spotted unless in combination with [X-Content-Type-Options|https://developer.mozilla.org/en-US/docs/Web/HTTP/...] header is present in the HTTP response too. This header effectively discourages browser to guess the Content-Type of the resource. > Output for directory-listing request in attached reproducer [^helloworld-html5.war]: > {code} > $ curl -v http://127.0.0.1:8080/helloworld-html5/css/ >/dev/null > * Trying 127.0.0.1... > * TCP_NODELAY set > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0) > > GET /helloworld-html5/css/ HTTP/1.1 > > Host: 127.0.0.1:8080 > > User-Agent: curl/7.59.0 > > Accept: */* > > > < HTTP/1.1 200 OK > < Connection: keep-alive > < Content-Length: 824 > < Date: Fri, 04 Jan 2019 14:32:46 GMT > < > { [824 bytes data] > 100 824 100 824 0 0 804k 0 --:--:-- --:--:-- --:--:-- 804k > * Connection #0 to host 127.0.0.1 left intact > {code} > Notice that there is no Content-Type header in HTTP response. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11637) Upgrade WildFly Core 8.0.0.Beta3

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/WFLY-11637?page=com.atlassian.jira.plugi... ] Flavia Rainone commented on WFLY-11637: --------------------------------------- Linking this Jira to WFLY Jira that was not marked as solved > Upgrade WildFly Core 8.0.0.Beta3 > -------------------------------- > > Key: WFLY-11637 > URL: https://issues.redhat.com/browse/WFLY-11637 > Project: WildFly > Issue Type: Component Upgrade > Components: Management > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Major > Fix For: 16.0.0.Beta1, 16.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4280) Undertow upgrade from 2.0.15.Final to 2.0.17.Final

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/WFCORE-4280?page=com.atlassian.jira.plug... ] Flavia Rainone commented on WFCORE-4280: ---------------------------------------- Linking to "ghost" Jira that was not marked as solved. > Undertow upgrade from 2.0.15.Final to 2.0.17.Final > -------------------------------------------------- > > Key: WFCORE-4280 > URL: https://issues.redhat.com/browse/WFCORE-4280 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Rostislav Svoboda > Assignee: Rostislav Svoboda > Priority: Major > Fix For: 8.0.0.Beta3, 8.0.0.Final > > > Undertow upgrade from 2.0.15.Final to 2.0.17.Final > https://github.com/undertow-io/undertow/compare/2.0.15.Final...2.0.17.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3064) Remove org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase test case.

by Parul Sharma (Jira)

[ https://issues.redhat.com/browse/WFLY-3064?page=com.atlassian.jira.plugin... ] Parul Sharma commented on WFLY-3064: ------------------------------------ Hi [~dlofthouse], Do you mind if i will remove this test case? Thanks, Parul Sharma > Remove org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase test case. > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-3064 > URL: https://issues.redhat.com/browse/WFLY-3064 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Darran Lofthouse > Priority: Major > > A new test case was added under WFLY-3063 that demonstrates the correct way to do this so now remove the original way that depended on internal APIs. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-11767) Remove unused dependencies from org.jboss.as.connector

by Parul Sharma (Jira)

[ https://issues.redhat.com/browse/WFLY-11767?page=com.atlassian.jira.plugi... ] Parul Sharma commented on WFLY-11767: ------------------------------------- Hi [~yersan], are you working on this issue? Thanks, Parul Sharma > Remove unused dependencies from org.jboss.as.connector > ------------------------------------------------------ > > Key: WFLY-11767 > URL: https://issues.redhat.com/browse/WFLY-11767 > Project: WildFly > Issue Type: Sub-task > Components: Class Loading > Reporter: Yeray Borges Santana > Assignee: Yeray Borges Santana > Priority: Major > > The analysis shows these dependencies are not used by this module: > * org.jboss.jts > * org.glassfish.javax.el -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3843) DMN Editor Decision Navigator differentiate icons for DRGElement

by Valentino Pellegrino (Jira)

[ https://issues.redhat.com/browse/DROOLS-3843?page=com.atlassian.jira.plug... ] Valentino Pellegrino reassigned DROOLS-3843: -------------------------------------------- Assignee: Valentino Pellegrino (was: Guilherme Gomes) > DMN Editor Decision Navigator differentiate icons for DRGElement > ---------------------------------------------------------------- > > Key: DROOLS-3843 > URL: https://issues.redhat.com/browse/DROOLS-3843 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Matteo Mortari > Assignee: Valentino Pellegrino > Priority: Major > Labels: drools-tools, ux_needed > Attachments: dmn-icons.png, image-2019-04-03-10-38-39-270.png > > > In this example: > !image-2019-04-03-10-38-39-270.png|thumbnail! > The 1st one is a Decision, the other are Input Data. > Experienced DMN practitioner may know that a decision logic can only happen to Decision or BKM node, hence one could distinguish potential Input data node by not having decision logic (context in the example). But also what about Decision or BKM for which you didn't write the decision logic yet? > PLease consider distinguished icon for DRG Elements. > For example > leave Input Data with the filled circle > Decision: filled square > BKM: filled trapezoid. > Thanks -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4775) Some .CLI commands that has been working since WF9 fails on WF18

by Peter Jonsson (Jira)

[ https://issues.redhat.com/browse/WFCORE-4775?page=com.atlassian.jira.plug... ] Peter Jonsson commented on WFCORE-4775: --------------------------------------- Just out of pure curiosity... may I ask a question to You guys; I found that the very same error occurs in EAP 7.3.0 . How does the "knowledge transfer" work in the Wildfly--->EAP? It seems like this one fell between the chairs... This error is a showstopper for all of our (isMobile) deliveries and now I have to bring our EAP customers to a halt before they upgrade to EAP 7.3 while all of our Wildfly customers are happy since they can go WF19 since last week. > Some .CLI commands that has been working since WF9 fails on WF18 > ---------------------------------------------------------------- > > Key: WFCORE-4775 > URL: https://issues.redhat.com/browse/WFCORE-4775 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 11.0.0.Beta4 > Reporter: Peter Jonsson > Assignee: Yeray Borges Santana > Priority: Critical > Fix For: 11.0.0.Beta5, 11.0.0.Final > > > Error message is > ERROR [org.jboss.as.cli.CommandContext] (CLI command) { > "outcome" => "failed", > "failure-description" => "java.lang.StackOverflowError:null" > } > And in the log > 2019-10-21 19:14:44,377 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{ > "address" => [("subsystem" => "undertow")], > "operation" => "write-attribute", > "name" => "statistics-enabled", > "value" => true, > "operation-headers" => { > "caller-type" => "user", > "access-mechanism" => "NATIVE" > } > }]: java.lang.StackOverflowError > at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:418) > at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392) > at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:426) > at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4775) Some .CLI commands that has been working since WF9 fails on WF18

by Peter Jonsson (Jira)

[ https://issues.redhat.com/browse/WFCORE-4775?page=com.atlassian.jira.plug... ] Peter Jonsson commented on WFCORE-4775: --------------------------------------- Can confirm that this is error is GONE in Wildfly 19. Thanks! > Some .CLI commands that has been working since WF9 fails on WF18 > ---------------------------------------------------------------- > > Key: WFCORE-4775 > URL: https://issues.redhat.com/browse/WFCORE-4775 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 11.0.0.Beta4 > Reporter: Peter Jonsson > Assignee: Yeray Borges Santana > Priority: Critical > Fix For: 11.0.0.Beta5, 11.0.0.Final > > > Error message is > ERROR [org.jboss.as.cli.CommandContext] (CLI command) { > "outcome" => "failed", > "failure-description" => "java.lang.StackOverflowError:null" > } > And in the log > 2019-10-21 19:14:44,377 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{ > "address" => [("subsystem" => "undertow")], > "operation" => "write-attribute", > "name" => "statistics-enabled", > "value" => true, > "operation-headers" => { > "caller-type" => "user", > "access-mechanism" => "NATIVE" > } > }]: java.lang.StackOverflowError > at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:418) > at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392) > at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:426) > at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4916) Investigate modify parsing bug in executable model

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4916?page=com.atlassian.jira.plug... ] Toshiya Kobayashi commented on DROOLS-4916: ------------------------------------------- Small correction: We should not have "$a" in the modify block because it fails with standard-drl. {noformat} modify ($a) { getCategories().add("hello"); } {noformat} Anyway, I can reproduce the issue with the above rule. > Investigate modify parsing bug in executable model > -------------------------------------------------- > > Key: DROOLS-4916 > URL: https://issues.redhat.com/browse/DROOLS-4916 > Project: Drools > Issue Type: Bug > Components: executable model > Reporter: Luca Molteni > Assignee: Toshiya Kobayashi > Priority: Major > Labels: good-first-issue > > {noformat} > declare Application > categories : Set = new HashSet() > end > {noformat} > Then I had a modify statement scattered about: > {noformat} > modify ($a) { > $a.getCategories().add("hello"); > } > {noformat} > The ExecutableModel did not seem to like any of those. I changed it to: > {noformat} > $a.getCategories().add("hello"); > update($a); > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2020