Possible bug with ETag in 304 responses - dev input requested
An issue came up on the Tomcat Users list about ETag headers and 304
responses. It seems (to me at least) there's a bug in Tomcat. Can
someone tell me if my analysis is correct? I would appreciate input
from developers who really know how this stuff is supposed to work.
The issue was originally raised by Joe Mun on the Tomcat Users list:
http://marc.info/?l=tomcat-user&m=117934336727314&w=2
I looked at the behaviour in Tomcat 5.5.23 and it looks like Tomcat is
not handling ETag headers as required by the HTTP spec, when it
returns a 304 ("not modified") response for a file. For a 304
response, the spec says:
"The response MUST include the following header fields:
...
- ETag and/or Content-Location, if the header would have been sent
in a 200 response to the same request"
(RFC 2616 10.3.5)
I take that to mean that if the server includes ETag headers when it
sends files, it must also include them when it sends 304's for those
same files. However Tomcat 5.5 doesn't do this. When a static file is
requested, Tomcat includes the ETag when it sends the file (with 200
status code) but omits it if it sends a status 304 response.
I did a simple test to verify this, requesting the same file twice to
get first a 200 and then a 304 response from Tomcat. The headers, as
reported by Firefox's Live HTTP Headers plugin, can be seen here:
http://marc.info/?l=tomcat-user&m=117950251422474&w=2
Am I correct that this is incorrect behaviour?
--
Len Popp
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible bug with ETag in 304 responses - dev input requested
On 5/20/07, Julian Reschke <[EMAIL PROTECTED]> wrote: Yes, I think that's correct. It's bug. OK then, I'll submit a bug report. -- Len Popp [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.24 candidate binaries
It's been running fine on Windows for a few days. -- Len On 6/20/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: how is 5.5.24 looking, if no one objects, I'll plan to start a vote on friday Filip Filip Hanik - Dev Lists wrote: > http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.24/ > will let these sit to mid next week, and then we can take a vote. > feedback between now and then is welcome at any time. > > Filip > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Juli/Logging
On 7/31/07, Rainer Jung <[EMAIL PROTECTED]> wrote: > My personal opinion: java.util.logging very much lacks a good formatter. > The default 2 line formatting of messages, splitting timestamps and > message in separate lines, is not really useful in production. Many ad > hoc log analysis practices work on a line oriented basis. How would exception stack traces be handled? That's an important consideration because a stack trace is the first thing people ask for when someone has a problem. :-) I like the idea of one line per entry, but stack traces don't seem to fit into that format. If you collapse a stack trace onto one line, it's a lot harder to read. If you keep the multi-line format for stack traces, you keep the same problem with log analysis practices that work on a line oriented basis. -- Len - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Juli/Logging
On 8/3/07, Costin Manolache <[EMAIL PROTECTED]> wrote: > On 8/2/07, Len Popp <[EMAIL PROTECTED]> wrote: > > > > On 7/31/07, Rainer Jung <[EMAIL PROTECTED]> wrote: > > > My personal opinion: java.util.logging very much lacks a good formatter. > > > The default 2 line formatting of messages, splitting timestamps and > > > message in separate lines, is not really useful in production. Many ad > > > hoc log analysis practices work on a line oriented basis. > > > > How would exception stack traces be handled? That's an important > > consideration because a stack trace is the first thing people ask for > > when someone has a problem. :-) > > I like the idea of one line per entry, but stack traces don't seem to > > fit into that format. If you collapse a stack trace onto one line, > > it's a lot harder to read. If you keep the multi-line format for stack > > traces, you keep the same problem with log analysis practices that > > work on a line oriented basis. > > > It's not only log tools who dislike the 2-line format - also humans. > > For a tool - detecting the stack trace is not that hard, it's a simple > pattern. > > But maybe a compact binary format would be more interesting for tools, and > could be converted to different layouts for people. > > Costin Oh, I'm one of the humans who prefers one line per entry - at least for short entries. I'm not against changing the log format. I'm just not sure if you can put a stack trace on one line and keep it readable. I wouldn't like to have a binary file format that I need a special program to read, or that is incompatible with standard tools like grep, tail, etc. -- Len - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Juli/Logging
OK, that's a useful compromise that makes log files easier to deal with. Suggestion: If the timestamp appeared on the first line of the stack trace (in addition to the preceding error message line), it would be easier to search a log file for an exception, say "OutOfMemoryException", and then locate that line in the file to see the rest of the info. For example: 2-Aug-2007 9:41:28 PM SEVERE: Servlet.service() for servlet Test threw exception 2-Aug-2007 9:41:28 PM java.lang.OutOfMemoryError at com.example.app.Test.testGenerateException(Test.java:115) at com.example.app.Test.doGet(Test.java:35) [etc.] -- Len On 8/3/07, Rainer Jung <[EMAIL PROTECTED]> wrote: > Stacks are always special. It's usually unfeasible to push them into one > line. My argument was about usual log messages. Of course in a fully > fledged new formatter, one would wish things like configuring the depth > of the stack printed. > > Len Popp wrote: > > On 7/31/07, Rainer Jung <[EMAIL PROTECTED]> wrote: > >> My personal opinion: java.util.logging very much lacks a good formatter. > >> The default 2 line formatting of messages, splitting timestamps and > >> message in separate lines, is not really useful in production. Many ad > >> hoc log analysis practices work on a line oriented basis. > > > > How would exception stack traces be handled? That's an important > > consideration because a stack trace is the first thing people ask for > > when someone has a problem. :-) > > I like the idea of one line per entry, but stack traces don't seem to > > fit into that format. If you collapse a stack trace onto one line, > > it's a lot harder to read. If you keep the multi-line format for stack > > traces, you keep the same problem with log analysis practices that > > work on a line oriented basis. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are Sticky Sessions really necessary?
You can indeed use session replication without sticky sessions, and the session data will be copied to all the Tomcat servers. However it may be inefficient. You probably have to use synchronous replication to ensure the session data is consistent across the cluster, which adds latency to the requests. And there could be a lot of extra network traffic in the cluster if it's busy (which it is, otherwise you wouldn't be doing load balancing). (I haven't used session replication in a high-load situation. Maybe someone else can tell us how well it works.) -- Len On 11/2/07, Stephen Wick <[EMAIL PROTECTED]> wrote: > The Tomcat 5.5 "Clustering/Session Replication Guide" says, "Make sure > that your loadbalancer is configured for sticky session mode." However, > I don't see the term "Sticky" sessions anywhere in the Servlet 2.3 or > 2.4 specifications. > > Are sticky sessions really required for clustering to function properly > in Tomcat 5.5? I thought that session replication would eliminate any > need to direct a client session to one node in a cluster. > > If not, can we adjust the documentation to indicate that Sticky sessions > are optional, for the appropriate reason (I'm guessing the advent of > session replication in tomcat.) > > I am asking this question because I am having trouble with Sticky > sessions in my load balancer, and I need to know whether or not I should > pursue fixing this feature. If tomcat doesn't really require sticky > sessions, then I can leave my load balancer alone. If tomcat does need > the feature to function properly, then I need to go to some additional > expense to resolve the issue with my load balancing appliance. > > Thank you for your time and expertise. > > Stephen Wick > Interactive Developer > Nicholson Kovac, Inc. > > References > http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are Sticky Sessions really necessary?
But isn't the purpose of session replication to allow different
servers to handle the session? If not, what's it for?
--
Len
On 11/3/07, Peter Rossbach <[EMAIL PROTECTED]> wrote:
> Hi,
>
> It is not only ineffizient and a risk, Read 7.7.2 at the spec:
>
> SRV.7.7.2 Distributed Environments
> Within an application marked as distributable, all requests that are
> part of a session
> must be handled by one Java Virtual Machine1 ("JVM") at a time. The
> container
> must be able to handle all objects placed into instances of the
> HttpSession class
> using the setAttribute or putValue methods appropriately.
> ....
>
> regards
> Peter
>
> Am 02.11.2007 um 22:37 schrieb Len Popp:
>
> > You can indeed use session replication without sticky sessions, and
> > the session data will be copied to all the Tomcat servers. However it
> > may be inefficient. You probably have to use synchronous replication
> > to ensure the session data is consistent across the cluster, which
> > adds latency to the requests. And there could be a lot of extra
> > network traffic in the cluster if it's busy (which it is, otherwise
> > you wouldn't be doing load balancing).
> >
> > (I haven't used session replication in a high-load situation. Maybe
> > someone else can tell us how well it works.)
> > --
> > Len
> >
> > On 11/2/07, Stephen Wick <[EMAIL PROTECTED]> wrote:
> >> The Tomcat 5.5 "Clustering/Session Replication Guide" says, "Make
> >> sure
> >> that your loadbalancer is configured for sticky session mode."
> >> However,
> >> I don't see the term "Sticky" sessions anywhere in the Servlet 2.3 or
> >> 2.4 specifications.
> >>
> >> Are sticky sessions really required for clustering to function
> >> properly
> >> in Tomcat 5.5? I thought that session replication would eliminate
> >> any
> >> need to direct a client session to one node in a cluster.
> >>
> >> If not, can we adjust the documentation to indicate that Sticky
> >> sessions
> >> are optional, for the appropriate reason (I'm guessing the advent of
> >> session replication in tomcat.)
> >>
> >> I am asking this question because I am having trouble with Sticky
> >> sessions in my load balancer, and I need to know whether or not I
> >> should
> >> pursue fixing this feature. If tomcat doesn't really require sticky
> >> sessions, then I can leave my load balancer alone. If tomcat does
> >> need
> >> the feature to function properly, then I need to go to some
> >> additional
> >> expense to resolve the issue with my load balancing appliance.
> >>
> >> Thank you for your time and expertise.
> >>
> >> Stephen Wick
> >> Interactive Developer
> >> Nicholson Kovac, Inc.
> >>
> >> References
> >> http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html
> >>
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
dev@tomcat.apache.org
The HTML 4 spec requires a "name=value" pair between the &'s, by my reading. Not necessarily in every URL, but at least when a form is submitted via a GET request. ref. http://www.w3.org/TR/html4/interact/forms.html#h-17.13.3.4 That's the commonest way to create URL query strings but not the *only* way, so I think it's appropriate to log a warning but not an error for non-compliant URLs. -- Len On Fri, Feb 29, 2008 at 1:43 PM, Mark Thomas <[EMAIL PROTECTED]> wrote: > Peter Rossbach wrote: > > Hi, > > > > I see the following warning with following request > > "http://localhost:8080/snoopy/snoopy.jsp?hello=xxx&&world=yyy"; > > > > Tomct 5.5.26 > > > > == > > 29.02.2008 13:49:29 org.apache.tomcat.util.http.Parameters > > processParameters > > WARNUNG: Parameters: Invalid chunk ignored. > > === > > > > Both parameter hello and world has the correct values, but every request > > logs a warning. At high > > traffic sites this anno user fault made admins really unhappy. > > > > At RFC 1738 only the following BNF are reference: > > That RFC is out of date. You want RFC 3986. > > Neither RFC actually defines how a parameter string should be formatted. I > did quite a bit of googling but the best reference I found was the JavaDoc > in the servlet spec for HttpUtils.parseQueryString() which suggests your > URL above does indeed have a suspect query string because of the double &&. > > Mark > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ISAPI Redirector issue | Building |
On Mon, Jun 14, 2010 at 10:51, Mladen Turk wrote: > You will also need the Server 2003r2 platform SDK, and if > building from GUI adjust the include and lib directories > from the SDK to take precedence over the ones from visual studio. > After you install the Server 2003 Platform SDK, here's how to tell Visual Studio 6 to use the new platform SDK: - Run VS6. - Open the View > Options dialog. - Add the appropriate directories for the Server 2003 Platform SDK. - Note that you must add include, lib and source directories separately, using the "Show directories for" dropdown. - Make sure the new directories are at the top of the list, so they are searched first. The procedure for Visual Studio 2008 is similar. FYI, the compile error messages have to do with items defined in httpext.h, which are not present in older versions of the Platform SDK. -- Len
