DO NOT REPLY [Bug 36742] - Missing diagnostics in InternalInputBuffer on overly long headers

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36742] - Missing diagnostics in InternalInputBuffer on overly long headers

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36742] - Missing diagnostics in InternalInputBuffer on overly long headers

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36742] - Missing diagnostics in InternalInputBuffer on overly long headers

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36742] - Missing diagnostics in InternalInputBuffer on overly long headers

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36742] - Missing diagnostics in InternalInputBuffer on overly long headers

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36742] New: - Missing diagnostics in InternalInputBuffer on overly long headers

gzilla/show_bug.cgi?id=36742 Summary: Missing diagnostics in InternalInputBuffer on overly long headers Product: Tomcat 5 Version: 5.0.28 Platform: Other OS/Version: other Status: NEW Severity: normal Pr

TIFF headers seem to have wrong sizes

My initial work seems to indicate that the headers of TIFF images being served have the size of the images more than twice what they should be. Is that possible or likely? Thanks -- "You can lead a horse to water but you cannot make it float on its back." ~D

HTTP headers and end of response, reposted for better reading

an Authentication-Info header in my response. This is the commonly accepted implementation scheme: If the login fails a 401 is sent thus: new login, when the login is ok an Authentication-Info header is send together with the normal 200 OK response. So what, "You can set headers i

HTTP headers and end of response

header in my response. This is the commonly accepted implementation: If the login fails a 401 is sent thus: new login, when the login is ok an Authentication-Info header is send together with the normal 200 OK response. So what, "You can set headers in the HttpServletResponse" would on

DO NOT REPLY [Bug 32499] - Headers: charset added to image Content-Type

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32499] New: - Headers: charset added to image Content-Type

gzilla/show_bug.cgi?id=32499 Summary: Headers: charset added to image Content-Type Product: Tomcat 5 Version: Unknown Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Ca

DO NOT REPLY [Bug 13846] - If-Modified-Since results in incorrect headers

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32038] - HTTP headers too large for buffer

gzilla/show_bug.cgi?id=32038 HTTP headers too large for buffer [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Reso

DO NOT REPLY [Bug 32038] New: - HTTP headers too large for buffer

gzilla/show_bug.cgi?id=32038 HTTP headers too large for buffer Summary: HTTP headers too large for buffer Product: Tomcat 5 Version: 5.0.29 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority:

DO NOT REPLY [Bug 14967] - Servet dies when very long request headers are encountered

gzilla/show_bug.cgi?id=14967 Servet dies when very long request headers are encountered [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RE

DO NOT REPLY [Bug 11105] - Get "Http10: Parse error, empty line" error while parsing headers

gzilla/show_bug.cgi?id=11105 Get "Http10: Parse error, empty line" error while parsing headers [EMAIL PROTECTED] changed: What|Removed |Added

Re: [PATCH] ./jk/native2/common/jk_worker_status.c - output non-caching headers

Guenter Knauf wrote: Hi, here's a patch to put non-caching headers out; maybe an 'Expires' header is also needed..? --- jk_worker_status.c.orig Fri Feb 27 12:24:12 2004 +++ jk_worker_status.c Sun Feb 29 19:30:24 2004 @@ -944,6 +944,10 @@ s->headers_out->pu

[PATCH] ./jk/native2/common/jk_worker_status.c - output non-caching headers

Hi, here's a patch to put non-caching headers out; maybe an 'Expires' header is also needed..? --- jk_worker_status.c.orig Fri Feb 27 12:24:12 2004 +++ jk_worker_status.c Sun Feb 29 19:30:24 2004 @@ -944,6 +944,10 @@ s->headers_out->pu

DO NOT REPLY [Bug 27073] - Only response body is sent and no HTTP headers on many GET and PROPFIND requests.

gzilla/show_bug.cgi?id=27073 Only response body is sent and no HTTP headers on many GET and PROPFIND requests. [EMAIL PROTECTED] changed: What|Removed |Added Status|RE

DO NOT REPLY [Bug 27073] - Only response body is sent and no HTTP headers on many GET and PROPFIND requests.

gzilla/show_bug.cgi?id=27073 Only response body is sent and no HTTP headers on many GET and PROPFIND requests. --- Additional Comments From [EMAIL PROTECTED] 2004-02-23 18:54 --- I investigated this more and I found that this bug can be caused by client webdav library (Delphi) that I am u

DO NOT REPLY [Bug 27073] - Only response body is sent and no HTTP headers on many GET and PROPFIND requests.

gzilla/show_bug.cgi?id=27073 Only response body is sent and no HTTP headers on many GET and PROPFIND requests. --- Additional Comments From [EMAIL PROTECTED] 2004-02-23 09:00 --- Yeah, right. You can download TC 4.1.30 if yo

DO NOT REPLY [Bug 27073] - Only response body is sent and no HTTP headers on many GET and PROPFIND requests.

gzilla/show_bug.cgi?id=27073 Only response body is sent and no HTTP headers on many GET and PROPFIND requests. --- Additional Comments From [EMAIL PROTECTED] 2004-02-23 08:50 --- On Tomcat 4.1.18 and 4.1.19 test works. On Tomcat 5.0.18 it does not work. So it was tested on two different conn

DO NOT REPLY [Bug 27073] - Only response body is sent and no HTTP headers on many GET and PROPFIND requests.

gzilla/show_bug.cgi?id=27073 Only response body is sent and no HTTP headers on many GET and PROPFIND requests. --- Additional Comments From [EMAIL PROTECTED] 2004-02-22 21:48 --- A simple servlet is a servlet which only depends on the servlet API, and a telnet displays very clearly the re

DO NOT REPLY [Bug 27073] - Only response body is sent and no HTTP headers on many GET and PROPFIND requests.

gzilla/show_bug.cgi?id=27073 Only response body is sent and no HTTP headers on many GET and PROPFIND requests. --- Additional Comments From [EMAIL PROTECTED] 2004-02-22 19:00 --- O.K. for now you have no proof that it is a bug, so you decision to resolve it is in my opinion correct for now.

DO NOT REPLY [Bug 27073] - Only response body is sent and no HTTP headers on many GET and PROPFIND requests.

gzilla/show_bug.cgi?id=27073 Only response body is sent and no HTTP headers on many GET and PROPFIND requests. --- Additional Comments From [EMAIL PROTECTED] 2004-02-20 09:50 --- Actually, I'd like this test to involve only telnets or simple servlets, without Slide, if possible. Otherwi

DO NOT REPLY [Bug 27073] - Only response body is sent and no HTTP headers on many GET and PROPFIND requests.

gzilla/show_bug.cgi?id=27073 Only response body is sent and no HTTP headers on many GET and PROPFIND requests. --- Additional Comments From [EMAIL PROTECTED] 2004-02-20 09:49 --- Actually, I'd like this test to involve only telnets or simple servlets, wi

DO NOT REPLY [Bug 27073] - Only response body is sent and no HTTP headers on many GET and PROPFIND requests.

gzilla/show_bug.cgi?id=27073 Only response body is sent and no HTTP headers on many GET and PROPFIND requests. --- Additional Comments From [EMAIL PROTECTED] 2004-02-20 09:44 --- It is corrupted http response (on PROPFIND method). I will try to prepare some test and configuration.Then I wil

DO NOT REPLY [Bug 27073] - Only response body is sent and no HTTP headers on many GET and PROPFIND requests.

gzilla/show_bug.cgi?id=27073 Only response body is sent and no HTTP headers on many GET and PROPFIND requests. --- Additional Comments From [EMAIL PROTECTED] 2004-02-19 10:16 --- Also submit: - dump of the HTTP traffic (for example, the corrupted request) - the configuration you&#x

DO NOT REPLY [Bug 27073] - Only response body is sent and no HTTP headers on many GET and PROPFIND requests.

gzilla/show_bug.cgi?id=27073 Only response body is sent and no HTTP headers on many GET and PROPFIND requests. [EMAIL PROTECTED] changed: What|Removed |Added Stat

DO NOT REPLY [Bug 27073] New: - Only response body is sent and no HTTP headers on many GET and PROPFIND requests.

gzilla/show_bug.cgi?id=27073 Only response body is sent and no HTTP headers on many GET and PROPFIND requests. Summary: Only response body is sent and no HTTP headers on many GET and PROPFIND requests. Product: Tomcat 5 Version: 5.0.18 Pl

DO NOT REPLY [Bug 9786] - org/apache/catalina/valves/RequestDumperValve logs all values x all headers

gzilla/show_bug.cgi?id=9786 org/apache/catalina/valves/RequestDumperValve logs all values x all headers [EMAIL PROTECTED] changed: What|Removed |Added Stat

DO NOT REPLY [Bug 25133] - Cannot add responses headers in filter after doFilter

gzilla/show_bug.cgi?id=25133 Cannot add responses headers in filter after doFilter --- Additional Comments From [EMAIL PROTECTED] 2003-12-02 12:40 --- No content is sent back on a 304. Only a header is sent to the client. With those situations, to response is not committed by the time do

DO NOT REPLY [Bug 25133] - Cannot add responses headers in filter after doFilter

gzilla/show_bug.cgi?id=25133 Cannot add responses headers in filter after doFilter --- Additional Comments From [EMAIL PROTECTED] 2003-12-02 12:11 --- Thanks Tim > To get around this - you need to wrap the ServletOutputStream and buffer it to > prevent it from being committed. Th

DO NOT REPLY [Bug 25133] - Cannot add responses headers in filter after doFilter

gzilla/show_bug.cgi?id=25133 Cannot add responses headers in filter after doFilter [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RE

DO NOT REPLY [Bug 25133] New: - Cannot add responses headers in filter after doFilter

gzilla/show_bug.cgi?id=25133 Cannot add responses headers in filter after doFilter Summary: Cannot add responses headers in filter after doFilter Product: Tomcat 5 Version: 5.0.14 Platform: PC OS/Version: Windows NT/2K Statu

DO NOT REPLY [Bug 5861] - java.lang.NumberFormatException when using non-standard HTTP headers with length of 8 characters and non numeric value

gzilla/show_bug.cgi?id=5861 java.lang.NumberFormatException when using non-standard HTTP headers with length of 8 characters and non numeric value [EMAIL PROTECTED] changed: What|Removed

DO NOT REPLY [Bug 234] - Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371

gzilla/show_bug.cgi?id=234 Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371 [EMAIL PROTECTED] changed: What|Removed |Added

DO NOT REPLY [Bug 234] - Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371

gzilla/show_bug.cgi?id=234 Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371 --- Additional Comments From [EMAIL PROTECTED] 2003-07-13 19:10 --- I was using mod_jk2-2.0.43.so (jk2 v2.0.1) downloaded from the jakarta site, and it appears that the

DO NOT REPLY [Bug 21297] - isapi_redirector2.dll cannot parse wrapped HTTP headers

gzilla/show_bug.cgi?id=21297 isapi_redirector2.dll cannot parse wrapped HTTP headers [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RE

DO NOT REPLY [Bug 21297] - isapi_redirector2.dll cannot parse wrapped HTTP headers

gzilla/show_bug.cgi?id=21297 isapi_redirector2.dll cannot parse wrapped HTTP headers --- Additional Comments From [EMAIL PROTECTED] 2003-07-03 04:30 --- Your example works perfectly with Apache & mod_jk on Solaris. I don't (personally) have access to an IIS server to continue inv

DO NOT REPLY [Bug 21297] - isapi_redirector2.dll cannot parse wrapped HTTP headers

gzilla/show_bug.cgi?id=21297 isapi_redirector2.dll cannot parse wrapped HTTP headers --- Additional Comments From [EMAIL PROTECTED] 2003-07-03 01:42 --- Note that the displayed value of "content-type" in each sample output is wrapped due to the input textarea size. The header name

DO NOT REPLY [Bug 21297] New: - isapi_redirector2.dll cannot parse wrapped HTTP headers

gzilla/show_bug.cgi?id=21297 isapi_redirector2.dll cannot parse wrapped HTTP headers Summary: isapi_redirector2.dll cannot parse wrapped HTTP headers Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Windows NT/2K Statu

DO NOT REPLY [Bug 13846] - If-Modified-Since results in incorrect headers

gzilla/show_bug.cgi?id=13846 If-Modified-Since results in incorrect headers [EMAIL PROTECTED] changed: What|Removed |Added Version|4.1.12 |

DO NOT REPLY [Bug 13846] - If-Modified-Since results in incorrect headers

gzilla/show_bug.cgi?id=13846 If-Modified-Since results in incorrect headers --- Additional Comments From [EMAIL PROTECTED] 2003-07-02 18:49 --- Created an attachment (id=7069) Patch to always set Content-Type/Content-Length headers in 304 re

isapi_redirector2 and wrapped headers: updated binary available?

Title: isapi_redirector2 and wrapped headers: updated binary available? I'm using IIS + Tomcat 4.1.24 + JK2 isapi_redirector2.dll. Everything has been working so far. However, now I'm receiving HTTP headers containing a Content-Type that is continued on another line, and isapi_r

Re: custom HTTP headers?

servlet API (and portable to other >containers) > >-Tim > >Adam Fisk wrote: >> I'm wondering if anyone can point me towards the class/classes that I >> should look at to add custom HTTP response headers for a customized >> Tomcat ap

Re: custom HTTP headers?

HttpServletResponse which is part of the servlet API (and portable to other containers) -Tim Adam Fisk wrote: I'm wondering if anyone can point me towards the class/classes that I should look at to add custom HTTP response headers for a customized Tomcat application I'm working o

custom HTTP headers?

I'm wondering if anyone can point me towards the class/classes that I should look at to add custom HTTP response headers for a customized Tomcat application I'm working on. Thanks very much. -Adam - To unsubscri

DO NOT REPLY [Bug 234] - Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371

gzilla/show_bug.cgi?id=234 Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371 [EMAIL PROTECTED] changed: What|Removed |Added Status|

DO NOT REPLY [Bug 234] - Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371

gzilla/show_bug.cgi?id=234 Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371 [EMAIL PROTECTED] changed: What|Removed |Added Stat

isapi_redirect.dll corrupts NTLM headers passed on?

Using the filter sevlet from the jcifs project (jcifs.samba.org), I can connect straight to tomcat with IE and use NTLM authentication to make getRemoteUser() return the right thing. However, using isapi_redirect.dll, jcifs gets corrupt data (an NTLM "type 3 message") and fails. I don't know exac

Invalid no-cache http headers

Since I already posted this to the user-mailing-list but did not get any usefull replies. And because I think this is actually a development question. Hi all, I encountered problems with the newer Tomcat 4 versions. There are caching-headers set on the response, in case of URL's with sec

DO NOT REPLY [Bug 14797] - Request headers are broken after invoking pageContext.include()

gzilla/show_bug.cgi?id=14797 Request headers are broken after invoking pageContext.include() [EMAIL PROTECTED] changed: What|Removed |Added CC||

DO NOT REPLY [Bug 15032] - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43

gzilla/show_bug.cgi?id=15032 Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43 [EMAIL PROTECTED] changed: What|Removed |Added Stat

DO NOT REPLY [Bug 15032] - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43

gzilla/show_bug.cgi?id=15032 Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43 --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 17:50 --- tested with mod_jk2.so version 2.0.2 has the same issue... -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> Fo

DO NOT REPLY [Bug 15032] - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43

gzilla/show_bug.cgi?id=15032 Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43 --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 14:27 --- Thanks to check with latest releases : jk 1.2.1 or jk 2.0.2 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTEC

DO NOT REPLY [Bug 15032] - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43

gzilla/show_bug.cgi?id=15032 Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43 --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 19:05 --- Created an attachment (id=4027) jk2 properties file for tomcat 4.1.12 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTEC

DO NOT REPLY [Bug 15032] - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43

gzilla/show_bug.cgi?id=15032 Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43 --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 19:05 --- Created an attachment (id=4026) workers2.properties for mod_jk2 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTEC

DO NOT REPLY [Bug 15032] - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43

gzilla/show_bug.cgi?id=15032 Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43 --- Additional Comments From [EMAIL PROTECTED] 2002-12-03 18:55 --- Created an attachment (id=4025) test case file that shows the bug -- To unsubscribe, e-mail: <mailto:[EMAIL PROTEC

DO NOT REPLY [Bug 15032] New: - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43

gzilla/show_bug.cgi?id=15032 Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43 Summary: Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43 Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/V

DO NOT REPLY [Bug 14967] - Servet dies when very long request headers are encountered

gzilla/show_bug.cgi?id=14967 Servet dies when very long request headers are encountered --- Additional Comments From [EMAIL PROTECTED] 2002-11-29 18:51 --- The exact length varies, but effects seem to start around 15K. On the other hand, Tomcat 4 and Apache httpd seem to limit the max. len

DO NOT REPLY [Bug 14967] - Servet dies when very long request headers are encountered

gzilla/show_bug.cgi?id=14967 Servet dies when very long request headers are encountered --- Additional Comments From [EMAIL PROTECTED] 2002-11-29 18:46 --- How long is a very long request header (bytes? example?) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional

DO NOT REPLY [Bug 14967] New: - Servet dies when very long request headers are encountered

gzilla/show_bug.cgi?id=14967 Servet dies when very long request headers are encountered Summary: Servet dies when very long request headers are encountered Product: Tomcat 3 Version: 3.3.1 Final Platform: PC OS/Version: Windows

DO NOT REPLY [Bug 14797] - Request headers are broken after invoking pageContext.include()

gzilla/show_bug.cgi?id=14797 Request headers are broken after invoking pageContext.include() [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RE

DO NOT REPLY [Bug 14797] - Request headers are broken after invoking pageContext.include()

gzilla/show_bug.cgi?id=14797 Request headers are broken after invoking pageContext.include() --- Additional Comments From [EMAIL PROTECTED] 2002-11-23 14:01 --- Created an attachment (id=3930) sample war file. Deploy and access /test/index.jsp -- To unsubscribe, e-mail: <mail

DO NOT REPLY [Bug 14797] New: - Request headers are broken after invoking pageContext.include()

gzilla/show_bug.cgi?id=14797 Request headers are broken after invoking pageContext.include() Summary: Request headers are broken after invoking pageContext.include() Product: Tomcat 4 Version: 4.1.12 Platform: PC OS/Version:

DO NOT REPLY [Bug 13846] - If-Modified-Since results in incorrect headers

gzilla/show_bug.cgi?id=13846 If-Modified-Since results in incorrect headers --- Additional Comments From [EMAIL PROTECTED] 2002-11-11 18:52 --- I looked into this 'cos I was skeptical, but you're right, this breaks the spec. 206 (Partial) responses to If-Range requests, and 3

[Coyote] Special headers handling

As I believe enforcing the protocol should be the responsability of the protocol handler, I have done (and will commit soon) a change which delegates setting the special headers (including "content-language" and "content-type") to the protocol handler. I will commit the cha

DO NOT REPLY [Bug 14386] - Date headers corrupted using setDateHeader

gzilla/show_bug.cgi?id=14386 Date headers corrupted using setDateHeader --- Additional Comments From [EMAIL PROTECTED] 2002-11-08 12:34 --- Note this bug is with Tomcat version 3.2.4 final (there was no option in the version list for this release). The behaiviour of the headers is corr

DO NOT REPLY [Bug 14386] New: - Date headers corrupted using setDateHeader

gzilla/show_bug.cgi?id=14386 Date headers corrupted using setDateHeader Summary: Date headers corrupted using setDateHeader Product: Tomcat 3 Version: 3.2.x Nightly Platform: All OS/Version: All Status: NEW Severity:

DO NOT REPLY [Bug 13846] - If-Modified-Since results in incorrect headers

gzilla/show_bug.cgi?id=13846 If-Modified-Since results in incorrect headers --- Additional Comments From [EMAIL PROTECTED] 2002-10-22 13:37 --- Just realised that my second example (going straight to tomcats HTTP/1.1 connector) doesn't seem right either. The header "Content-Lenght:

DO NOT REPLY [Bug 13846] New: - If-Modified-Since results in incorrect headers

gzilla/show_bug.cgi?id=13846 If-Modified-Since results in incorrect headers Summary: If-Modified-Since results in incorrect headers Product: Tomcat 4 Version: 4.1.12 Platform: All OS/Version: Other Status: NEW Severity:

[Patch] Make mod_jk2 send REDIRECT_* headers for ErrorDocument usage

Hi, The attached patch for mod_jk2 (apache 1.3 and apache 2.0) sends a REDIRECT_URL and a REDIRECT_QUERYSTRING header if the request inside apache is redirected (e.g. through the use of the ErrorDocument directive). This follows the environment variables detailed in http://httpd.apache.org/docs

DO NOT REPLY [Bug 234] - Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371

gzilla/show_bug.cgi?id=234 Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371 [EMAIL PROTECTED] changed: What|Removed |Added Component

DO NOT REPLY [Bug 11647] - Encoding of Response Headers Violates HTTP Spec.

gzilla/show_bug.cgi?id=11647 Encoding of Response Headers Violates HTTP Spec. [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RE

Question about the processing of Cookie: headers.

Hello .. One of my compatriots is having a problem with a 3rd party peice of software that attempting to access a Tomcat 4.0.4 server. The 3rd party software .. acting as a client .. is sending a requst with a cookie: header with the following value .. JSESSIONID=F40180928E56604E197E25DE

Headers

On Tue, 20 Aug 2002, Patrick Luby wrote: > > Are you and Costin comfortable with Steve Downey's latest proposal > (headers are split on "," for only the headers explicitly defined in the > HTTP/1.1 specification)? I am not. I am ok ( and I think it is required

Re: Watchdog aggregation of headers may be incorrect

comma. So getHeader() can ( and probably should ) return the concatenated values. getHeaders() is a different story - I don't think it can or should take single-line headers and split it. It seems the spec defines all extension headers as 'entity headers', but I don't see

Re: Watchdog aggregation of headers may be incorrect

On Sunday 18 August 2002 11:02 am, [EMAIL PROTECTED] wrote: > My understanding - the HTTP spec doesn't ( and can't ) define a complete > list of headers supporting multiple values. That's impossible given that > additional headers are supported. > The spec does exac

Re: Watchdog aggregation of headers may be incorrect

My understanding - the HTTP spec doesn't ( and can't ) define a complete list of headers supporting multiple values. That's impossible given that additional headers are supported. If the servlet spec requires getHeader() to return the 'concatenated value for multi-headers&#x

Re: Watchdog aggregation of headers may be incorrect

d, as per the spec definition. >> > > > Ah. That's where we're going in separate directions. I'm assuming that it is > known. The HTTP spec defines which headers are comma separated. So it's just > a matter of checking against that list in order to know

Re: Watchdog aggregation of headers may be incorrect

ot just > >>>getHeaders() is affected. getHeader() must be also. getHeader, if there > >>>are multiple values, needs to return the same thing as the first value > >>>returned by getHeaders(), not the whole header from the first of > >>> multiple hea

Re: Watchdog aggregation of headers may be incorrect

there >>>are multiple values, needs to return the same thing as the first value >>>returned by getHeaders(), not the whole header from the first of multiple >>>headers. >> >>Sorry, but no. The opposite statement doesn't work. >>getHeader MUST re

Re: Watchdog aggregation of headers may be incorrect

to return the same thing as the first value > > returned by getHeaders(), not the whole header from the first of multiple > > headers. > > Sorry, but no. The opposite statement doesn't work. > getHeader MUST return the first header line, unless in the case there > are m

Re: Watchdog aggregation of headers may be incorrect

gt;>>>> header1: val2 >>>> >>>>No, this is not correct. >>>> >>>>You are allowed to do that only if the application knows it makes sense >>>>to do so (ie, only when it call getHeaders). >>> >>>If it is to

Re: Watchdog aggregation of headers may be incorrect

gt;>You are allowed to do that only if the application knows it makes sense > >>to do so (ie, only when it call getHeaders). > > > > If it is to be done, it should be done based on what the HTTP/1.1 spec > > defines. The application needs to expect the possibility of mu

Re: Watchdog aggregation of headers may be incorrect

On Saturday 17 August 2002 12:13 pm, Patrick Luby wrote: > Remy, > > Remy Maucherat wrote: > > No, this is not correct. > > > > You are allowed to do that only if the application knows it makes sense > > to do so (ie, only when it call getHeaders). > > > > Some code to do that should be added in t

Re: Watchdog aggregation of headers may be incorrect

eaders). >> > > > If it is to be done, it should be done based on what the HTTP/1.1 spec > defines. The application needs to expect the possibility of multiple values > for all of the headers that allow them. Or just ask for the first one. > Parsing the header line into

Re: Watchdog aggregation of headers may be incorrect

ines. The application needs to expect the possibility of multiple values for all of the headers that allow them. Or just ask for the first one. Parsing the header line into values probably shouldn't be left to the application, although it is at the moment. > Some code to do that should b

Re: Watchdog aggregation of headers may be incorrect

hat should be added in the adapter. > > > This makes more sense than my original thoughts since the Watchdog > failures are only happening in tests that invoke the getHeaders() method. > >> >> No, this musn't be done there, as it would screw up many headers. >>

Re: Watchdog aggregation of headers may be incorrect

iginal thoughts since the Watchdog failures are only happening in tests that invoke the getHeaders() method. > > No, this musn't be done there, as it would screw up many headers. Please > read the chapter on multivalued headers in the HTTP/1.1 spec. > Which class do you suggest

Re: Watchdog aggregation of headers may be incorrect

Servlet spec non-compliance. However, I am > not sure where the parsing of headers is now performed in Tomcat? > > Can anyone point Steve to where this header parsing of the ServerSocket > input stream is being done? No, this musn't be done there, as it would screw up many head

Re: Watchdog aggregation of headers may be incorrect

cing the older o.a.c.connector.http.HttpProcessor. Looking at it, it does a lot more detailed parsing of the HTTP headers while receiving the request. Coyote does a lot more lazy evaluation, holding everything in MessageBytes for as long as possible. This saves on unnecessary object creation and GC. > This s

Re: Watchdog aggregation of headers may be incorrect

Are you sure? Well, of course you're sure. What I mean is, is this a good interpretation of the spec? The spec is not crystal clear on this point [SRV.4.3], as it discusses multiple headers with the same name, and multiple values for headers, but that seems to be within context of mul

Re: Watchdog aggregation of headers may be incorrect

- Original Message - From: "Patrick Luby" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Friday, August 16, 2002 6:43 PM Subject: Re: Watchdog aggregation of headers may be incorrect > Steve, > > Your assess

Re: Watchdog aggregation of headers may be incorrect

fixed as it is Servlet spec non-compliance. However, I am not sure where the parsing of headers is now performed in Tomcat? Can anyone point Steve to where this header parsing of the ServerSocket input stream is being done? Patrick Steve Downey wrote: > Watchdog now merges headers, by design.

Watchdog aggregation of headers may be incorrect

Watchdog now merges headers, by design. ie (from the checking message) Modified logic to send duplicate headers as one aggregated header vs. two headers: header1: val1 header1: val2 -will now be- header1: val1, val2 Due to this, it looks like a couple of tests are failing

DO NOT REPLY [Bug 11647] New: - Encoding of Response Headers Violates HTTP Spec.

gzilla/show_bug.cgi?id=11647 Encoding of Response Headers Violates HTTP Spec. Summary: Encoding of Response Headers Violates HTTP Spec. Product: Tomcat 4 Version: 4.1.8 Platform: All OS/Version: All Status: UNCONFIRMED Severity:

DO NOT REPLY [Bug 11105] New: - Get "Http10: Parse error, empty line" error while parsing headers

gzilla/show_bug.cgi?id=11105 Get "Http10: Parse error, empty line" error while parsing headers Summary: Get "Http10: Parse error, empty line" error while parsing headers Product: Tomcat 3 Version: 3.3.1 Final Platf

  1   2   >