JSP vs Servlet, Built‑in Objects, Scopes, Session vs Cookie, Spring MVC vs Struts, and Web Security Practices

Java Web

64. What is the difference between JSP and Servlet?

JSP is compiled into a Servlet; the web container translates JSP code into a Java class that the JVM can execute.

JSP is better suited for page presentation, while Servlets are better for business logic control.

Servlets have no built‑in objects; JSP’s implicit objects are accessed through HttpServletRequest , HttpServletResponse and HttpServlet .

JSP simplifies Servlet development: developers only need to output content, and the JSP container handles embedding Java code into a class, whereas a Servlet is a full Java class with a service method that generates the response.

65. What are the JSP implicit objects and their purposes?

JSP provides nine implicit objects:

request : encapsulates client request parameters (GET or POST).

response : encapsulates the server’s response to the client.

pageContext : gives access to all other implicit objects.

session : represents the user’s session.

application : represents the servlet context (global scope).

out : the output stream for sending content to the client.

config : the servlet configuration object.

page : the JSP page itself (similar to this in Java).

exception : encapsulates any exception thrown on the page.

66. What are the four JSP scopes?

page : objects and attributes related to a single page.

request : objects and attributes that live for the duration of a single HTTP request, possibly spanning multiple pages.

session : objects and attributes tied to a user’s session with the server.

application : objects and attributes that are shared across the entire web application.

67. What is the difference between Session and Cookie?

Because HTTP is stateless, the server uses a Session to keep track of a user’s state. The Session is stored on the server and identified by a unique Session ID, which can be kept in memory, a database, or a file, and may be replicated in a cluster.

Cookies are client‑side pieces of data. When a Session is first created, the server sends a Cookie containing the Session ID to the browser; the browser returns this Cookie on subsequent requests, allowing the server to associate the request with the correct Session. If cookies are disabled, URL rewriting (e.g., appending sid=xxxxx ) can be used to propagate the Session ID.

68. How does a Session work?

A Session is essentially a server‑side hash table that stores key‑value pairs. The key is the Session ID (often stored in a cookie), and the value is the data associated with that user. When a request arrives with the Session ID, the server retrieves the corresponding data.

69. Can Session be used when the client disables cookies?

Yes. Alternatives include:

Enabling URL rewriting via session.use_trans_sid = 1 in php.ini or compiling with --enable-trans-sid .

Manually passing the Session ID through hidden form fields or URL parameters.

Storing the Session ID in a file or database and manually retrieving it across pages.

70. What are the differences between Spring MVC and Struts?

Interception mechanism : Struts2 uses class‑level interceptors (a new Action instance per request), while Spring MVC uses method‑level interception with each controller method handling its own request/response.

Underlying framework : Struts2 relies on a Filter (StrutsPrepareAndExecuteFilter); Spring MVC uses a DispatcherServlet . Filters are initialized at container startup, whereas Servlets are initialized on first request.

Performance : Spring MVC’s controller beans are singleton by default, reducing object creation overhead, leading to higher development efficiency and better performance compared with Struts2’s per‑request Action objects.

Configuration : Spring MVC integrates seamlessly with the Spring ecosystem, offering better management and security features than Struts2.

71. How to prevent SQL injection?

Use PreparedStatement (simple and effective).

Validate input with regular expressions.

Perform string filtering.

In JSP, call a function that checks for illegal characters.

Implement validation logic directly in JSP pages.

72. What is XSS and how to prevent it?

Cross‑Site Scripting (XSS) occurs when an attacker injects malicious HTML/JavaScript into a vulnerable web page, which is then executed in the victim’s browser. Prevention strategy: filter all input (including URL parameters) and encode output.

73. What is CSRF and how to prevent it?

Cross‑Site Request Forgery (CSRF) tricks a logged‑in user’s browser into sending unwanted requests to a trusted site. Common defenses include:

1. Verify the HTTP Referer header

Check that the Referer originates from the same site before processing sensitive actions.

2. Use CAPTCHAs

Require a CAPTCHA on critical operations to ensure a human is initiating the request.

3. Add a token to the request and validate it

Generate a random token stored in the session and include it as a hidden field, e.g., <input type="hidden" name="csrftoken" value="tokenvalue"/> , or as a URL parameter like csrftoken=tokenvalue . The server validates the token on each request.

4. Use a custom HTTP header

Send the token in a custom header (e.g., X‑CSRF‑Token ) via XMLHttpRequest, which is not automatically included in cross‑origin requests.

(End)