On 28/01/2021 16:54, bugzi...@apache.org wrote:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
>
> --- Comment #83 from Suzon Ali ---
Yet another idiot who fails to realise that all the links from Bugzilla
are "no follow".
I'll get this vandalism cleaned up.
Mark
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #83 from Suzon Ali ---
https://allnewjobcircular.com/hsc-bm-computer-office-application-assignment/;>HSC
BM Computer Office Application Assignment along with the more relative term
is for everyone is that of
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #82 from Suzon Ali ---
The https://allnewjobcircular.com/ssc-syllabus-pdf/;>SSC Syllabus
2021 is available now for everyone. https://allnewjobcircular.com/hsc-syllabus-pdf/;>HSC Syllabus 2021
can make a good help for every
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #81 from Suzon Ali ---
I am very much delighted with your information. You can get the same on me here
as you can see now at https://resultofficial.com/;>Result Official
can be the most demanded in the world with accurate
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #80 from Suzon Ali ---
Thanks for your information about https://allnewjobcircular.com/hsc-result/;>HSC Result 2020 now. Then
https://allnewjobcircular.com/hsc-auto-pass-result/;>HSC Auto Pass
Result 2020 can be the most demanded
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
Matthew Buckett changed:
What|Removed |Added
CC||buck...@bumph.org
--- Comment #79
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
Julian Reschke changed:
What|Removed |Added
CC||julian.resc...@gmx.de
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #78 from Ralf Hauser ---
see also Bug 62964
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail:
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #77 from Julian Reschke ---
(In reply to Ralf Hauser from comment #72)
> First, there are many error conditions for which no precise 4xx or 5xx code
> is defined. So in this way, the reason might be helpful.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #76 from Michael Osipov <1983-01...@gmx.net> ---
(In reply to Christopher Schultz from comment #74)
> (In reply to Michael Osipov from comment #73)
> > (In reply to Ralf Hauser from comment #72)
> > > First, there are many error
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #75 from Ralf Hauser ---
(In reply to Michael Osipov from comment #73)
> No, use a given status code and augment it with application/problem+json or
> similar. The Status text cannot be set via Servlet API anyway.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #74 from Christopher Schultz ---
(In reply to Michael Osipov from comment #73)
> (In reply to Ralf Hauser from comment #72)
> > First, there are many error conditions for which no precise 4xx or 5xx
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #73 from Michael Osipov <1983-01...@gmx.net> ---
(In reply to Ralf Hauser from comment #72)
> First, there are many error conditions for which no precise 4xx or 5xx code
> is defined. So in this way, the reason might be helpful.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #72 from Ralf Hauser ---
First, there are many error conditions for which no precise 4xx or 5xx code is
defined. So in this way, the reason might be helpful.
While I understand that an html browser can display more
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #71 from Michael Osipov <1983-01...@gmx.net> ---
(In reply to Mark Thomas from comment #70)
> That is a view although it is perhaps a tad harsh.
>
> Regardless, the world is moving towards HTTP/2 and HTTP/2 doesn't have a
> reason
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #70 from Mark Thomas ---
That is a view although it is perhaps a tad harsh.
Regardless, the world is moving towards HTTP/2 and HTTP/2 doesn't have a reason
phrase so this is a situation developers are going to
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #69 from Michael Osipov <1983-01...@gmx.net> ---
(In reply to William Watson from comment #68)
> I believe an option to send a reason phrase should be maintained in Tomcat 9.
>
> The reason phrase should be ignored by RFC-compliant
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #68 from William Watson ---
I believe an option to send a reason phrase should be maintained in Tomcat 9.
The reason phrase should be ignored by RFC-compliant client software. But RFC
compliant software is not
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #67 from Michael Osipov <1983-01...@gmx.net> ---
(In reply to Fred Simon from comment #66)
> For info Debian Apt (some may think it's also IoT - as Trash) is also
> hardcoded to expect a reason phrase :(
> Was fixed for http:
>
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #66 from Fred Simon ---
For info Debian Apt (some may think it's also IoT - as Trash) is also hardcoded
to expect a reason phrase :(
Was fixed for http:
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #65 from Olivier Jaquemet ---
Hi,
Just so you know, BitKinex WebDAV client is impacted by this missing reason
phrase and it can no longer access any webdav servlet configured in Tomcat
unless
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
Christopher Schultz changed:
What|Removed |Added
CC|
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #63 from Christopher Schultz ---
First of all, let's all settle down. Reasonable people can disagree about
whether this change is a Good Thing or a Bad Thing and whether options should
exist to
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #62 from mgrigorov ---
(In reply to Ralph Moser from comment #61)
> Your next argument is that you are going to provide maintenance forever for
> 8.5. That's great but we may want to use new features. Also we
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #61 from Ralph Moser ---
Ok.
You have the code to add the reason phrase. It's in contrast to headers not
easily fixable in most reverse proxies. Why aren't you just keeping the option
to add it? We have
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #60 from Mark Thomas ---
To provide a some context / background.
7.0.x, 8.0.x always send the reason phrase
8.5.x does not send the reason phrase by default but can be configured to do so
9.0.x does not send the
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #59 from mgrigorov ---
(In reply to thorsten.meinl from comment #58)
> Even if this change doesn't break clients it will give a very bad impression
> to users. For example if you use Java to issue HTTP request
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #58 from thorsten.me...@knime.com ---
Even if this change doesn't break clients it will give a very bad impression to
users. For example if you use Java to issue HTTP request and and error was
returned by the server, the exception
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #57 from Silas Smith ---
(In reply to mgrigorov from comment #56)
>
> Why you can use old clients and not use old servers ?!
> 6.x has been just discontinued, so I expect that 8.5.x will be maintained
> for
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #56 from mgrigorov ---
(In reply to Silas Smith from comment #55)
> I'm missing the point about why it's so important for tomcat to no longer
> send the reason phrase, such that even keeping it as optional is
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #55 from Silas Smith ---
I'm missing the point about why it's so important for tomcat to no longer send
the reason phrase, such that even keeping it as optional is being so strongly
argued against?
I'm glad
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #54 from Blazej Bucko ---
Yes, that's true. But, according to older spec, it's perfectly legal for
clients to rely on this information. And removing the reason phrase breaks
them.
--
You are receiving this
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #53 from Mark Thomas ---
(In reply to Blazej Bucko from comment #52)
> They were not broken according to the first RFC. They broke around 2014 when
> new RFC was published.
Nope. From RFC 2616 (dated 1999):
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #52 from Blazej Bucko ---
They were not broken according to the first RFC. They broke around 2014 when
new RFC was published.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #51 from slav...@gmail.com ---
I agree, but there lot of "broken" software, working everywhere in the world
Isn't too early to drop legacy support?
Even apache 2.4 proxy stops working without reason phrase
ProxyPass
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #50 from Michael Osipov <1983-01...@gmx.net> ---
(In reply to slavb18 from comment #49)
> Cannot understand, why, without any reason, all legacy clients should be
> broken with server update.
They where already broken before. You
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #49 from slav...@gmail.com ---
Cannot understand, why, without any reason, all legacy clients should be broken
with server update.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #48 from Violeta Georgieva ---
Hi,
(In reply to Michael Osipov from comment #47)
> (In reply to Violeta Georgieva from comment #45)
> > Hi,
> >
> > A new Connector configuration 'sendReasonPhrase' is added.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #47 from Michael Osipov <1983-01...@gmx.net> ---
(In reply to Violeta Georgieva from comment #45)
> Hi,
>
> A new Connector configuration 'sendReasonPhrase' is added. When this
> attribute is set to 'true', a reason phrase will be
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #46 from Remy Maucherat ---
Ok, it's a good compromise then if 8.0 indeed does not go on (I'll believe that
when it actually happens ;) ).
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
Violeta Georgieva changed:
What|Removed |Added
Resolution|--- |FIXED
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #44 from mgrigorov ---
+1 for the change!
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe,
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #43 from Violeta Georgieva ---
(In reply to Remy Maucherat from comment #42)
> Ok, I thought the 8.0 plan was long gone. But the patch is only for 8.5 then
> ? If so, then I can withdraw the -1.
The patch is
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #42 from Remy Maucherat ---
Ok, I thought the 8.0 plan was long gone. But the patch is only for 8.5 then ?
If so, then I can withdraw the -1.
--
You are receiving this mail because:
You are the assignee for the
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #41 from Mark Thomas ---
One of the main reasons 8.0.x is maintained is because this option isn't
available in 8.5.x. (The other is the sendfile issues which I think we are
getting to the bottom of).
The patch
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #40 from Remy Maucherat ---
-1. It should be removed at some point, so let it be now. It turns out (given
what I see) that we're going to maintain 7.0 and 8.0 for at least as long as
8.5, so it's good enough.
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #39 from Violeta Georgieva ---
Hi,
I created a patch that adds an option for sending a reason phrase with the
response.
https://github.com/apache/tomcat85/pull/7
By default a reason phrase will not be sent
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #38 from Ralph Moser ---
Please provide some option to reenable the reason phrase. We have several
embedded systems which are not able to work without it. Yes they are not
standard compliant but it's not
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #37 from Neil Brown ---
Hi,
I've read through the discussion of this issue to date, in both the original
bug report and this enhancement request.
The Reason Phrase may be optional in the HTTP spec,
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #36 from Todd Pierce ---
Appeal to Reason (phrase).
As I stated in comment 4, my interpretation is the spec does not state that the
reason phrase is optional, it simply says it is allowed to be zero
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #35 from Blazej Bucko ---
But it is not explicitly forbidden (especially when one reads the next
sentence). It would also mean that, according to rfc2616, humans are forbidden
to look at Status Code.
I
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #34 from Mark Thomas ---
(In reply to Blazej Bucko from comment #33)
> That's true. But client that relies on information provided in Reason Phrase
> is also spec-compliant. And you are implying that it's not.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #33 from Blazej Bucko ---
That's true. But client that relies on information provided in Reason Phrase is
also spec-compliant. And you are implying that it's not.
--
You are receiving this mail because:
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #32 from Mark Thomas ---
(In reply to Blazej Bucko from comment #31)
> OK. I'd also like to point out that RFC 7230 mentioned in some of the
> comments is quite new (2014). Even legacy systems (in this case
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #31 from Blazej Bucko ---
OK. I'd also like to point out that RFC 7230 mentioned in some of the comments
is quite new (2014). Even legacy systems (in this case systems that are older
than 2-3 years), which
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #30 from Michael Osipov <1983-01...@gmx.net> ---
(In reply to Blazej Bucko from comment #29)
> Are you sure that you are still spec-compliant? rfc2616 defines Reason
> Phrase as part of Status Line. Additionally, spec suggests that
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #29 from Blazej Bucko ---
Are you sure that you are still spec-compliant? rfc2616 defines Reason Phrase
as part of Status Line. Additionally, spec suggests that it is for automata
only clients are not
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #28 from Ken DeLong ---
Our situation is the same as Todd's: we can and do upgrade our own firmware,
but cannot update the manufacturer's.
I tried making a Valve that wrapped the Response object, and
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #27 from Todd Pierce ---
(In reply to Michael Osipov from comment #26)
> (In reply to Ken DeLong from comment #25)
> > We have switched to another chip maker, and in any event, the chips that are
> >
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #26 from Michael Osipov <1983-01...@gmx.net> ---
(In reply to Ken DeLong from comment #25)
> We have switched to another chip maker, and in any event, the chips that are
> out in the field are out there, no way to upgrade except by
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #25 from Ken DeLong ---
We have switched to another chip maker, and in any event, the chips that are
out in the field are out there, no way to upgrade except by replacing them.
--
You are receiving this mail
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #24 from Michael Osipov <1983-01...@gmx.net> ---
(In reply to Ken DeLong from comment #22)
> I talked to our firmware guys - the offending code is actually in Texas
> Instruments firmware on the chip we use. So there are likely
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #23 from Michael Osipov <1983-01...@gmx.net> ---
(In reply to Ralf Hauser from comment #21)
> I am also in favour of allowing the reason code.
>
> Although the discussion so far appears to be odd.
>
> > "HTTP/1.1 200 Fine, mate!"
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #22 from Ken DeLong ---
I talked to our firmware guys - the offending code is actually in Texas
Instruments firmware on the chip we use. So there are likely many devices
affected, although I'm sure not all
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #21 from Ralf Hauser ---
I am also in favour of allowing the reason code.
Although the discussion so far appears to be odd.
> "HTTP/1.1 200 Fine, mate!"
is probably of little value.
However in particular in the
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #20 from Christopher Schultz ---
(In reply to Michael Osipov from comment #16)
> (In reply to Remy Maucherat from comment #15)
> > The only good place to put all these non upgradeable IoT devices is
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #19 from Ken DeLong ---
And mine are in consumer electronic devices...
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #18 from Todd Pierce ---
(In reply to Remy Maucherat from comment #15)
> The only good place to put all these non upgradeable IoT devices is the
> trash.
In my case the devices are head units inside
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #17 from Josh Soref ---
These devices should be behind a firewall/proxy (to protect them from the scary
Internet).
Your firewall/proxy can manage the 200 OK fix for you. That way if you upgrade
to Tomcat 9,
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #16 from Michael Osipov <1983-01...@gmx.net> ---
(In reply to Remy Maucherat from comment #15)
> The only good place to put all these non upgradeable IoT devices is the
> trash.
Therefore, IoT = Internet of Trash
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #15 from Remy Maucherat ---
The only good place to put all these non upgradeable IoT devices is the trash.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #14 from Ken DeLong ---
For a short time, I'm happy to run on 8.0.x (that's what I'm doing now). But
that's unsustainable; eventually the rest of my tech stack (Spring Boot) will
outpace me and I'll be in a
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #13 from Mark Thomas ---
Is running on 7.0.x or 8.0.x not an option?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #12 from Ken DeLong ---
Our software interfaces with IoT devices which contain firmware (beyond our
control) that expects the "OK" (they parse for "200 OK"; just "200" is parsed
as an error).
I'm sympathetic
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
Ken DeLong changed:
What|Removed |Added
CC|
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #11 from Mateusz Nowakowski ---
>What about "HTTP/1.1 200 Fine, mate!"? This would work or hard requirement for
>"OK"?
For me it is not a requirement to tune reason phase.
However I dig into it and saw that there
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #10 from Josh Soref ---
https://github.com/jech/polipo/blob/master/tunnel.c#L302
const char *message = "HTTP/1.1 200 Tunnel established\r\n\r\n";
--
You are receiving this mail because:
You are the assignee for
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #9 from Michael Osipov <1983-01...@gmx.net> ---
(In reply to Mateusz Nowakowski from comment #8)
> >Do your clients require just some text after the space or do they really
> >analyze >the text for predefined values?
>
> They
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #8 from Mateusz Nowakowski ---
>Do your clients require just some text after the space or do they really
>analyze >the text for predefined values?
They analyze the text, however they are compatible with previous
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #7 from Michael Osipov <1983-01...@gmx.net> ---
(In reply to Mateusz Nowakowski from comment #6)
> Facts:
> 8.0.39 still returns the reason phase.
> 8.5.x and onward do not return the reason phase.
>
> Purpose of this story is to
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
Mateusz Nowakowski changed:
What|Removed |Added
Version|8.0.x-trunk |8.5.x-trunk
---
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
Mark Thomas changed:
What|Removed |Added
CC||matih...@o2.pl
---
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
Michael Osipov <1983-01...@gmx.net> changed:
What|Removed |Added
CC|
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #4 from Todd Pierce ---
I suggest that the spec for HTTTP 1.1 is ambiguous regarding whether the reason
phrase is optional at all. It says that the reson phrase is defined as zero or
more text
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #3 from Todd Pierce ---
Reinstating the reason phrase to 8.0.x would be a good outcome.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
Christopher Schultz changed:
What|Removed |Added
Version|8.5.x-trunk
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
--- Comment #1 from Remy Maucherat ---
No.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail:
https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
Mark Thomas changed:
What|Removed |Added
Severity|normal |enhancement
88 matches
Mail list logo