🧠 What is URL Rewriting?

✅ URL Rewriting is a technique where you append extra information (like a session ID or user data) into the URL itself,
so that the server can track the user even if the client doesn’t support cookies.

📖 In simple words:

“If the browser can’t or won’t store cookies,
then pass the session ID inside the URL itself.” 🎯

🎯 How URL Rewriting Looks

✅ Example of a URL with rewriting:

https://example.com/shop;JSESSIONID=ABC123XYZ456

;JSESSIONID=ABC123XYZ456 is the rewritten part.

It carries the session ID back and forth between client and server.

🚀 Why Use URL Rewriting?

Reason	Explanation
Cookies disabled	Some browsers block cookies, but we still need session tracking.
Fallback mechanism	Servlet containers automatically fall back to URL rewriting if cookies don’t work.
Control	You explicitly control how session data is passed in links/forms.

---

⚙️ How to Implement URL Rewriting in Servlets

✅ Java servlets provide built-in support:

When building a link:

String rewrittenUrl = response.encodeURL("profile.jsp");

• encodeURL() will automatically:
  • If cookies work ➔ return normal URL.
  • If cookies don’t work ➔ append session ID into the URL.

✅ Usage in servlet response:

PrintWriter out = response.getWriter();
out.println("<a href='" + response.encodeURL("profile.jsp") + "'>Profile</a>");

✅ Similarly, when redirecting:

response.sendRedirect(response.encodeRedirectURL("welcome.jsp"));

🔥 Very Important:

• You must use encodeURL() and encodeRedirectURL() if you want session tracking to work even when cookies are disabled.
• If you just hard-code URLs without encoding, you risk breaking sessions for cookie-disabled users.

⚡ Example Without and With URL Rewriting

Case	URL
Without URL rewriting (normal)	/profile.jsp
With URL rewriting (cookies disabled)	/profile.jsp;JSESSIONID=ABC123XYZ456

🛠️ When exactly does the server use URL rewriting?

• Servlet container (e.g., Tomcat) checks:
  • Are cookies enabled?
  • Did the browser return the JSESSIONID cookie?
• If no cookie, and you used encodeURL(), then the server adds ;JSESSIONID=... to URLs automatically.

---

⚡ Quick Practical Tip:

Situation	Best Practice
You create a URL manually	Always call encodeURL()
You send a redirect	Always call encodeRedirectURL()

---

🧠 Quick Memory Trick:

“URL Rewriting is Plan B: If the browser won’t carry cookies,
carry the session ID inside the URL!” 🎯

---

🔥 Quick Summary Table:

| | Cookies | URL Rewriting | |:—|:—| | Client needs to store something? | ✅ Yes | ❌ No | | Session ID visible? | ❌ No | ✅ Yes (in URL) | | Secure? | Less secure (session ID exposed in URL) | | Automatic in servlets? | ✅ With encodeURL() |

✅ To delete a cookie:

1. Create a new cookie with the same name as the one you want to delete.
2. Set its Max-Age to 0.
3. (Optional but important) Set the same path as the original cookie (otherwise it might not match).

Finally, add it to the response.

🎯 Example: Deleting a Cookie

Cookie cookie = new Cookie("userName", "");  // Name must match
cookie.setMaxAge(0);                         // 0 means delete immediately
cookie.setPath("/");                         // Must match original path
response.addCookie(cookie);                  // Add it back to instruct browser

✅ What happens:

• When the browser receives a cookie with Max-Age=0, it removes the cookie immediately.

---

⚡ Important Things to Remember:

Point	Why
Cookie name must match exactly	Otherwise the browser doesn’t know which cookie to remove
Cookie path must match	If path differs, it won’t recognize the cookie to delete
Domain (if set originally) must match	Otherwise browser might keep old cookie
Always addCookie() even for deletion	Deleting is just sending a “zero-age” cookie back

---

🚀 Practical Full Example

✅ Suppose you earlier created:

Cookie cookie = new Cookie("userName", "Alice");
cookie.setMaxAge(3600);
cookie.setPath("/");
response.addCookie(cookie);

✅ Now to delete it later:

Cookie deleteCookie = new Cookie("userName", "");
deleteCookie.setMaxAge(0);
deleteCookie.setPath("/");
response.addCookie(deleteCookie);

🔥 Real Life Scenario

• After a user logs out, you usually delete session-related cookies like “userId” or “JSESSIONID” (if not managed automatically).
• Important for security and privacy.

---

🛠️ Quick Summary:

Can I delete a cookie?	✅ Yes
How?	Set Max-Age = 0 and addCookie()
Should name and path match original?	✅ Yes, absolutely
Browser behavior	Browser removes the cookie immediately

---

⚡ Final Memory Trick:

“To delete a cookie: same name + same path + Max-Age 0 + send it back.” 🎯

🧠 In Servlets, you work with cookies using the javax.servlet.http.Cookie class.

Here’s the full list of the main methods for working with cookies:

---

🎯 Methods of the Cookie Class

Method	Purpose	Example
getName()	Get the cookie name	cookie.getName()
getValue()	Get the cookie value	cookie.getValue()
setValue(String value)	Set/change the cookie value	cookie.setValue("newValue")
getDomain()	Get the domain for the cookie	cookie.getDomain()
setDomain(String pattern)	Set the domain (e.g., .example.com)	cookie.setDomain(".example.com")
getPath()	Get the path for which the cookie is valid	cookie.getPath()
setPath(String uri)	Set the path (e.g., /shop)	cookie.setPath("/shop")
getMaxAge()	Get the lifetime of the cookie in seconds	cookie.getMaxAge()
setMaxAge(int expiry)	Set how long the cookie should live (in seconds)	cookie.setMaxAge(3600)
getSecure()	Check if cookie is sent only over HTTPS	cookie.getSecure()
setSecure(boolean flag)	Force cookie to be sent only over HTTPS	cookie.setSecure(true)
isHttpOnly()	Check if cookie is HttpOnly	cookie.isHttpOnly()
setHttpOnly(boolean isHttpOnly)	Set cookie as HttpOnly (inaccessible to JS)	cookie.setHttpOnly(true)
toString()	Get cookie info as a String	cookie.toString()

---

🛠️ Other Important Servlet Methods for Working with Cookies

✅ From HttpServletResponse:
(Used for sending cookies to the client)

Method	Purpose
addCookie(Cookie cookie)	Add a cookie to the response

✅ From HttpServletRequest:
(Used for reading cookies sent by the client)

Method	Purpose
getCookies()	Returns an array of Cookie objects from the request

🚀 Full Mini Example:

✅ Setting a cookie:

Cookie cookie = new Cookie("userName", "Alice");
cookie.setMaxAge(60 * 60); // 1 hour
cookie.setPath("/"); // Make cookie available for entire app
cookie.setSecure(true); // Send only over HTTPS
cookie.setHttpOnly(true); // Prevent JavaScript access
response.addCookie(cookie);

✅ Reading cookies:

Cookie[] cookies = request.getCookies();
if (cookies != null) {
    for (Cookie cookie : cookies) {
        if ("userName".equals(cookie.getName())) {
            String value = cookie.getValue();
            // Use value
        }
    }
}

✅ Deleting a cookie:

Cookie cookie = new Cookie("userName", "");
cookie.setMaxAge(0); // 0 means delete immediately
cookie.setPath("/");
response.addCookie(cookie);

⚡ Quick Practical Tips:

Tip	Why
Always set a path (setPath("/"))	Otherwise, cookie might not be visible to all your pages
Use setHttpOnly(true) for sensitive cookies	Improves security (prevent XSS attacks)
Use setSecure(true) if your app uses HTTPS	Prevents cookie leakage over HTTP
Remember cookies are small!	Browsers limit cookie size (~4KB) and number of cookies

🔥 Quick Memory Trick:

“Cookies in servlets = Create (addCookie), Read (getCookies), Delete (setMaxAge(0)).” 🎯

✅ Cookies are small pieces of data (key-value pairs) that a server sends to the client’s browser,
and the browser stores them and automatically sends them back to the server with each future request to the same server.

Think of cookies as the server leaving a note inside your browser:
→ “Hey, remember this next time!”

---

🎯 How Cookies Work Step-by-Step:

1. Server sends a cookie using the Set-Cookie header.
2. Browser stores the cookie locally (temporary or persistent).
3. For every future request to that server, the browser attaches the cookie using a Cookie header.

---

✅ Example:

• Server sends:

Set-Cookie: userId=12345; Max-Age=3600; Path=/

Browser stores it.

Next request automatically adds:

Cookie: userId=12345

Server can now recognize the user!

🚀 Why are Cookies Useful?

Use Case	Example
Session tracking	Keeping users logged in
Personalization	Remembering user preferences (theme, language)
Analytics	Tracking user visits
Shopping carts	Remembering items added to cart

🛠️ Cookies in Servlets

✅ To create a cookie:

Cookie cookie = new Cookie("username", "Alice");
cookie.setMaxAge(3600); // 1 hour
response.addCookie(cookie);

✅ To read cookies:

Cookie[] cookies = request.getCookies();
if (cookies != null) {
    for (Cookie cookie : cookies) {
        if ("username".equals(cookie.getName())) {
            String value = cookie.getValue();
            // Use value
        }
    }
}

⚡ Important Properties of Cookies:

Property	Description
Name	Key (must be unique per domain+path)
Value	Associated data (can be string, needs encoding if special characters)
Domain	Which domain the cookie belongs to
Path	Which path the cookie applies to (e.g., /shop)
Max-Age	Lifetime in seconds (0 = delete immediately, no set = session cookie)
Secure	Only send cookie over HTTPS
HttpOnly	Can’t be accessed by JavaScript (for security)
SameSite	Controls cross-site behavior (Lax, Strict, None)

🧩 Types of Cookies:

Type	Meaning
Session Cookies	Temporary, deleted when browser closes (no Max-Age set)
Persistent Cookies	Stored until expiration date (Max-Age or Expires set)
Secure Cookies	Sent only over HTTPS
HttpOnly Cookies	Not accessible by client-side scripts (prevents XSS attacks)

---

🛡️ Quick Example: Secure Login Session

✅ Server after login success:

Cookie sessionCookie = new Cookie("JSESSIONID", "ABC123XYZ");
sessionCookie.setHttpOnly(true);
sessionCookie.setSecure(true);
sessionCookie.setMaxAge(30 * 60); // 30 minutes
response.addCookie(sessionCookie);

🔥 Quick Practical Tip:

✅ Use cookies for small, essential data only.
❌ Don’t store sensitive information directly in cookies (like passwords!) — always store tokens, IDs, or references.

✅ Use HttpOnly and Secure flags whenever dealing with authentication cookies!

⚡ Quick Memory Trick:

“Cookies are your browser’s little notes from the server —
small, helpful, and sometimes a little too revealing.” 🎯

✅ Session Management means tracking user interactions across multiple HTTP requests.

Because:

• HTTP is stateless by design.
• Every HTTP request is independent — the server forgets everything about the previous request.
• So if you want a user to “stay logged in”, “keep items in cart”, “remember settings” — you must explicitly manage session state!

🎯 Different Methods of Session Management in Servlets

Method	How it works	Description
Cookies	Store a session ID in a small text file in the browser	Most common default way
URL Rewriting	Add session ID as part of URL query string	Backup if cookies are disabled
Hidden Form Fields	Pass session ID manually in hidden <input> fields	Only works for form submissions
HttpSession API	Java object automatically tied to session ID	Easiest and most robust way in Servlets

🚀 Now, Let’s Understand Each One Carefully:

---

✅ 1. Cookies

• Server sends a Set-Cookie header with a session ID.
• Browser stores it and automatically sends it back with each request.

✅ Server-side in servlet:

HttpSession session = request.getSession();
session.setAttribute("username", "Alice");

Browser sees:

Set-Cookie: JSESSIONID=ABC123DEF456

Next request will automatically include:

Cookie: JSESSIONID=ABC123DEF456

⚡ If cookies are disabled, this method won’t work unless you fallback to URL rewriting.

✅ 2. URL Rewriting

• When cookies are disabled, server can append session ID to URLs.

Example:

https://example.com/profile;JSESSIONID=ABC123DEF456

✅ In Java, you use:

String encodedURL = response.encodeURL("profile.jsp");

• encodeURL() will automatically append session ID only if needed (if cookies are not working).

⚡ Drawbacks:

• Session ID is visible in URL (security risk if copied/shared).

✅ 3. Hidden Form Fields

• Pass session ID manually inside a form as a hidden input field.

Example:

<form action="checkout" method="POST">
    <input type="hidden" name="sessionId" value="ABC123DEF456">
    <input type="submit" value="Checkout">
</form>

✅ Server reads:

String sessionId = request.getParameter("sessionId");

⚡ Problems:

• Only works if user submits forms (not for normal URL clicks).
• Manual management needed — annoying and risky.

✅ 4. HttpSession API (Servlet Built-in)

• Servlet containers (like Tomcat) handle all session tracking for you automatically.
• You work with HttpSession object.

✅ Example:

HttpSession session = request.getSession();
session.setAttribute("username", "Alice");

String username = (String) session.getAttribute("username");

✅ Features:

• Timeout configuration.
• Session invalidation (session.invalidate()).
• Attribute management (store any Java objects).

✅ Best practice: always prefer HttpSession API unless you have very special needs.

🧠 What Happens if You Don’t Encode Symbols in a URL?

• The browser or server may misinterpret your URL.
• Special symbols have specific meanings in URLs.
• If they are not properly encoded, they can break the URL structure or cause wrong behavior.

🎯 Examples: What Happens With Some Symbols

Symbol	Meaning in URL	What happens if unencoded?
?	Start of query parameters	Everything after ? is treated as a parameter list
&	Separates parameters	Starts a new parameter
=	Separates key and value	Defines the value for a parameter
#	Start of fragment	Browser jumps to fragment, server ignores everything after #
/	Path separator	Treated as a new directory
+	In form encoding, means space	Could be misinterpreted if not handled correctly

🔥 Real Examples:

---

✅ Example 1: & without encoding

Suppose you want to send:

product=Fish & Chips

And you build URL:

https://example.com/menu?dish=Fish & Chips

Browser interprets:

• dish=Fish (before &)
• and a new parameter Chips without a value!

⚡ Wrong parsing!

✅ Correct:

String dish = "Fish & Chips";
String encodedDish = URLEncoder.encode(dish, StandardCharsets.UTF_8);

Result:

https://example.com/menu?dish=Fish+%26+Chips

Now server correctly reads:
dish = Fish & Chips

---

✅ Example 2: # without encoding

Suppose you send:

https://example.com/search?query=fun#games

What happens?

• Browser sees #games as a fragment (like a bookmark inside the page).
• Server only receives /search?query=fun — everything after # is NOT sent to server.

⚡ Server never sees “games” at all!

✅ Correct way:

You must encode #:

• %23

Then:

https://example.com/search?query=fun%23games

Now server receives query=fun#games.

✅ Example 3: = without encoding

Suppose:

name=John=Smith

Without encoding:

https://example.com/register?name=John=Smith

Browser/server might think:

• name = John
• Extra =Smith confuses parsers.

✅ Correct way:

Encode = as %3D inside parameter value.

🚀 Quick Practical Rule:

If symbol is used for…	Problem
Structure of URL (like ?, &, =, /, #)	Must encode if part of data!
Data value itself (like text)	Always encode!

✅ Always encode data values, not the structural parts.

---

⚡ Quick Summary

	Without Encoding	With Encoding
Fish & Chips	Breaks into 2 parameters	Encoded properly
fun#games	Fragment ignored by server	Encoded as %23
John=Smith	Confuses key=value parsing	Encoded as %3D

---

🛠️ Final Memory Trick:

“If it’s data, encode it.”
“If it’s URL structure, leave it alone.”

🧠 What is URL Encoding?

✅ URL encoding is the process of translating special characters in a URL into a format that can be safely transmitted over the Internet.

In URLs:

• Only letters, digits, and a few special characters (-, _, ., ~) are allowed as-is.
• Spaces, symbols (@, #, ?, =, /, etc.) must be encoded.

🔵 Encoding replaces unsafe characters with a % followed by two hexadecimal digits.

✅ Example:

Character	Encoded as
Space ()	%20
@	%40
:	%3A
/	%2F
?	%3F
&	%26

🎯 Why do we need URL encoding?

• To safely pass data inside URLs without confusion.
• To avoid breaking the URL structure.
• To transmit non-ASCII characters (like ü, ç, 你好) safely over HTTP.

If you don’t encode properly:

• URLs can get corrupted.
• Parameters might be misinterpreted.

⚙️ How to Do URL Encoding in Java

✅ Java provides a built-in class: java.net.URLEncoder

Example:

import java.net.URLEncoder;
import java.nio.charset.StandardCharsets;

public class UrlEncodeExample {
    public static void main(String[] args) {
        String original = "Hello World! @2024";
        String encoded = URLEncoder.encode(original, StandardCharsets.UTF_8);
        System.out.println(encoded);
    }
}

✅ Output:

Hello+World%21+%402024

🔵 Note:

• Spaces become + (in application/x-www-form-urlencoded).
• Special characters are encoded as %XX.

🛠️ Important:

• Always specify the character encoding (usually UTF-8).
• Don’t forget to decode later if needed using URLDecoder.decode()!

import java.net.URLDecoder;

String decoded = URLDecoder.decode(encoded, StandardCharsets.UTF_8);
System.out.println(decoded); // back to "Hello World! @2024"

🔥 Example: Sending data safely in a query parameter

Suppose you want to create a link like:

https://example.com/search?query=Hello World! @2024

✅ Correct way:

String query = "Hello World! @2024";
String encodedQuery = URLEncoder.encode(query, StandardCharsets.UTF_8);

String url = "https://example.com/search?query=" + encodedQuery;
System.out.println(url);

Result:

https://example.com/search?query=Hello+World%21+%402024

🛡️ Warning:

Situation	Correct Approach
Encoding full URL	❌ Don’t encode the whole URL blindly (only parameters!)
Encoding query parameters	✅ Always encode values (key/value parts)
Encoding path segments	✅ Encode separately if needed

---

🚀 Quick Summary

Concept	Meaning
URL Encoding	Convert unsafe characters in a URL into safe %XX format
Java class	URLEncoder.encode(String, Charset)
Common encoding	UTF-8
Also decode	Use URLDecoder.decode() when needed

🧠 What is SingleThreadModel?

✅ SingleThreadModel is an interface that was introduced in early Servlet API versions (Servlet 2.0) to guarantee that:

Only one thread can execute the servlet’s service() method at a time per servlet instance.

🎯 How It Worked:

If your servlet implemented SingleThreadModel:

public class MyServlet extends HttpServlet implements SingleThreadModel {
    // servlet code
}

✅ The container (e.g., Tomcat) ensured that:

• Each request is handled one at a time for each servlet instance.
• OR the container creates a pool of servlet instances to handle multiple requests safely.

✅ Result:

• No two threads could access the same servlet instance at the same time.
• It was supposed to make servlets thread-safe easily.

⚡ But there were BIG problems:

Problem	Why it mattered
Performance impact	Slowed down server a lot — couldn’t use threads fully
Didn’t really solve all thread issues	Shared resources (like database connections, static fields) could still cause problems
Complexity for server implementers	Containers had to create and manage multiple servlet instances
Developers misunderstood it	Thought “thread safe” meant “no need to think anymore” — which was wrong

---

🚨 Important: SingleThreadModel is Deprecated!

• Deprecated since Servlet 2.4 (around 2003).
• Removed in Servlet 3.1+ (modern servers don’t use it anymore).

✅ Today, best practice is to:

• Write thread-safe code manually.
• Avoid shared mutable state inside servlets.
• Use local variables, thread-safe collections (ConcurrentHashMap, AtomicInteger), or proper synchronization when necessary.

---

🛠️ Quick Example

❌ Old style:

public class OldServlet extends HttpServlet implements SingleThreadModel {
    private int counter = 0; // No synchronization needed because only one thread!

    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        counter++;
        resp.getWriter().println("Counter: " + counter);
    }
}

✅ Modern style (no SingleThreadModel, safe by design):

public class SafeServlet extends HttpServlet {
    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        int counter = 0; // local to the method = no thread issues
        counter++;
        resp.getWriter().println("Counter: " + counter);
    }
}

🔥 Quick Summary

Question	Answer
What is SingleThreadModel?	An interface to make servlet instances accessed by only one thread at a time.
Why it existed?	To make servlets “thread-safe” easily.
Why it’s bad?	Killed performance, didn’t solve real-world multi-threading issues.
Status now?	Deprecated and not recommended.
Modern advice?	Manually design thread-safe servlets without SingleThreadModel.

---

⚡ Final Memory Trick:

“SingleThreadModel was training wheels… but now developers must ride the bike themselves. 🚲“

✅ Always design servlets as multi-threaded apps today!

❌ No, you cannot use both PrintWriter and ServletOutputStream simultaneously in a servlet for the same response.

It is forbidden by the Servlet specification.
Mixing them causes IllegalStateException.

---

🧠 Why?

• The response can either be character-based (PrintWriter) or byte-based (ServletOutputStream).
• Not both.
• Once you get one, the underlying response output handling is set (to either character encoding mode or binary mode).
• Mixing would break the HTTP response stream.

---

⚡ Example of what NOT to do:

protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    
    PrintWriter writer = response.getWriter();
    ServletOutputStream outputStream = response.getOutputStream(); // ❌ WRONG!
}

✅ As soon as you call response.getWriter(), trying to call response.getOutputStream() will throw an exception at runtime.

Or vice versa.

🎯 Servlet Specification (Official) says:

If getWriter() has been called, then calling getOutputStream() must throw an IllegalStateException, and vice versa.

🚀 How to decide which one to use?

Situation	Use
You send text (HTML, JSON, plain text)	PrintWriter
You send binary data (images, PDFs, zip files)	ServletOutputStream

✅ Always pick one early when building the response, depending on what you’re sending.

🛠️ Correct usage examples

✅ Use only PrintWriter:

protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    response.setContentType("text/html; charset=UTF-8");
    PrintWriter out = response.getWriter();
    out.println("<h1>Hello World!</h1>");
}

✅ Use only ServletOutputStream:

protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    response.setContentType("application/octet-stream");
    ServletOutputStream out = response.getOutputStream();
    out.write(new byte[]{1, 2, 3, 4});
}

🔥 Super Quick Summary:

	PrintWriter	ServletOutputStream
Type	Character stream	Byte stream
getWriter() locks response into	Character mode
getOutputStream() locks response into	Binary mode
Use both together?	❌ NO, IllegalStateException

Both are used to send data from your servlet back to the client as part of the HTTP response.

But they are a little different:

Feature	PrintWriter	ServletOutputStream
Data type	Character stream (text data)	Byte stream (binary data)
Best for	Writing textual content (HTML, JSON, plain text)	Writing binary content (images, PDFs, videos, file downloads)
Returned by	response.getWriter()	response.getOutputStream()
Encoding control	Automatically handles encoding (e.g., UTF-8)	You manually control bytes
Ease of use	Easier for text	Needed for non-text (images, files)

---

🎯 In simpler words:

• PrintWriter:
  • Works with characters (strings, text).
  • Buffered, convenient for writing HTML, JSON, plain text.
• ServletOutputStream:
  • Works with raw bytes (binary).
  • Needed when you send binary data like files, images, etc.

🛠️ Tiny Example:

✅ Using PrintWriter for text:

protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    response.setContentType("text/html");
    PrintWriter out = response.getWriter();
    out.println("<h1>Hello, World!</h1>");
}

✅ Using ServletOutputStream for binary data:

protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    response.setContentType("application/octet-stream");
    ServletOutputStream out = response.getOutputStream();
    byte[] data = {0x48, 0x65, 0x6C, 0x6C, 0x6F}; // "Hello" in bytes
    out.write(data);
}

⚡ Important Rule:

You can’t use both getWriter() and getOutputStream() in the same response!

• If you call response.getWriter(), you cannot later call response.getOutputStream().
• And vice versa.
• Doing so causes IllegalStateException.

Because:

• Writer and OutputStream are two different ways to manage the response body, and mixing them would break the HTTP response format.

---

🔥 Quick Practical Tip:

You want to send…	Use…
HTML page	PrintWriter
JSON response	PrintWriter
Text file (plain text)	PrintWriter
Image (PNG, JPEG)	ServletOutputStream
PDF document	ServletOutputStream
Zip file download	ServletOutputStream

---

🚀 Bonus Tip:

If you use PrintWriter, you should always set the character encoding early, for example:

response.setCharacterEncoding("UTF-8");
response.setContentType("text/html; charset=UTF-8");

Otherwise the server default encoding (ISO-8859-1) might be used, causing weird text problems.

🛠️ Quick Summary Table:

Aspect	PrintWriter	ServletOutputStream
Type	Text / Character stream	Binary / Byte stream
Use for	HTML, JSON, plain text	Images, files, binary blobs
Method	response.getWriter()	response.getOutputStream()
Can mix them?	❌ No	❌ No