Return-Path: Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 77143 invoked from network); 12 Sep 2000 00:43:54 -0000 Received: from msp-26-164-174.mn.rr.com (HELO localhost.localdomain) (24.26.164.174) by locus.apache.org with SMTP; 12 Sep 2000 00:43:54 -0000 Received: from fatman (IDENT:nobody@localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with SMTP id SAA11416 for ; Mon, 11 Sep 2000 18:41:45 -0500 Message-ID: <134732893.968715705797.JavaMail.nobody@fatman> Date: Mon, 11 Sep 2000 18:41:45 -0500 (CDT) From: BugRat Mail System Reply-To: BugRat Mail System To: tomcat-bugs@cortexity.com Subject: BugRat Report #102 has been filed. Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="134735845.968715705766.JavaMail.nobody@fatman" X-Mailer: org.gjt.mail.EnhancedMimeMsg, Organization: The Giant Java Tree, X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N --134735845.968715705766.JavaMail.nobody@fatman Content-Type: text/plain Content-Transfer-Encoding: 7bit Bug report #102 has just been filed. You can view the report at the following URL: REPORT #102 Details. Project: Servlet API Category: Bug Report SubCategory: New Bug Report Class: webbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: Servlet API 1.2 JVM Release: 1.3.3 Operating System: Solaris OS Release: 8 Platform: Sparc Synopsis: sendRedirect clears HTTP headers Description: A call to HttpServletResponse.sendRedirect clears all HTTP headers before sending its redirect response. This makes it difficult to do something like add a cookie, and then redirect the client. i.e. protected void doGet(HttpServletRequest request, HttpServletResponse response) { Cookie cookie = new Cookie("my", "cookie"); response.addCookie(cookie); response.sendRedirect("to-subsystem"); } The sendRedirect call clears the addCookie from the response headers. I can imagine that this might not actually be a bug. In my thinking and experience, the above code is perfectly legal HTTP processing. But perhaps there is a design consideration for doing it this way. I understand that with the current Servlet implementation, it is possible to send a redirect after data has been written to the output stream. I do believe though that this feature should not supercede the flexibility of the sendRedirect command. --134735845.968715705766.JavaMail.nobody@fatman Content-Type: text/html; name=Report-102.html Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=Report-102.html Content-Description: DataSource attachment 'Report-102.html' BugRat Report # 102

BugRat Report # 102

Project: Servlet API Release: Servlet API 1.2
Category: Bug Report SubCategory: New Bug Report
Class: webbug State: received
Priority: medium Severity: serious
Confidence: public

Submitter: Chris Johnson ( tenorviol@yahoo.com )
Date Submitted: Sep 11 2000, 06:41:45 CDT
Responsible: Z_Tomcat Alias ( tomcat-bugs@cortexity.com )

Synopsis:
sendRedirect clears HTTP headers
Environment: (jvm, os, osrel, platform)
1.3.3, Solaris, 8, Sparc

Additional Environment Description:

Report Description:
A call to HttpServletResponse.sendRedirect clears all HTTP headers before sending its redirect response. This makes it difficult to do something like add a cookie, and then redirect the client. i.e. protected void doGet(HttpServletRequest request, HttpServletResponse response) { Cookie cookie = new Cookie("my", "cookie"); response.addCookie(cookie); response.sendRedirect("to-subsystem"); } The sendRedirect call clears the addCookie from the response headers. I can imagine that this might not actually be a bug. In my thinking and experience, the above code is perfectly legal HTTP processing. But perhaps there is a design consideration for doing it this way. I understand that with the current Servlet implementation, it is possible to send a redirect after data has been written to the output stream. I do believe though that this feature should not supercede the flexibility of the sendRedirect command.

Workaround:
null

View this report online...
--134735845.968715705766.JavaMail.nobody@fatman--