Câu hỏi: PRJ301 Phát triển ứng dụng Java web – Bộ ôn tập cuối kỳ số 2
50 câu trắc nghiệm kèm lời giải của môn PRJ301 - Phát triển ứng dụng Java web, xếp đúng thứ tự trong đề.
Danh sách câu hỏi
20/50 câuCòn 30
1What is inside a HTTP response?6 lựa chọn
AA result code and Header fields
BA request code and response code
CBody and ACK flag
DBody and Header fields
EBoth A and D is true
FAll of above
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "Both A and D is true". Một phản hồi HTTP gồm dòng trạng thái mang mã kết quả, khối header, rồi phần body, nên hai mô tả về mã kết quả cùng header và về body cùng header đều đúng một phần và chỉ lựa chọn gộp cả hai mới kể đủ cấu trúc. "A result code and Header fields" đúng ở mã kết quả và header nhưng bỏ mất body, nơi chứa nội dung thật sự trả về. "Body and Header fields" đúng ở body và header nhưng bỏ mất mã kết quả, thứ cho trình duyệt biết yêu cầu thành công, bị chuyển hướng hay lỗi. "A request code and response code" sai vì phản hồi không mang mã của yêu cầu, bản thân yêu cầu cũng không có mã mà chỉ có phương thức và đường dẫn. "Body and ACK flag" sai vì ACK là cờ của tầng vận chuyển TCP, nằm ngoài khuôn dạng thông điệp HTTP. "All of above" sai vì nó gộp luôn cả hai mô tả không đúng vừa nêu.
AGET encrypts data, ensuring secure transmission.
BPOST is more suitable for secure data transfer.
CGET exposes sensitive data in the URL.
DGET can handle larger data volumes than POST.
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "GET exposes sensitive data in the URL.". Với GET, tham số được nối vào query string nên chúng hiện trên thanh địa chỉ và còn đọng lại trong lịch sử trình duyệt, trong bookmark, trong header Referer và trong log của web server hay proxy; đó là lý do không đặt mật khẩu hoặc số thẻ vào GET. "GET encrypts data, ensuring secure transmission." sai vì không phương thức HTTP nào tự mã hoá dữ liệu, việc mã hoá do lớp TLS của HTTPS làm và nó bảo vệ GET với POST như nhau. "POST is more suitable for secure data transfer." có phần hợp lý ở chỗ POST đặt dữ liệu trong body nên không phơi ra URL, nhưng nó nói về POST chứ không trả lời cách GET xử lý dữ liệu nhạy cảm, và bản thân POST cũng không mã hoá gì. "GET can handle larger data volumes than POST." sai vì ngược lại: độ dài URL bị trình duyệt và server giới hạn, còn POST đặt dữ liệu trong body nên chứa được nhiều hơn.
3What happens to request attributes when sendRedirect() is used?4 lựa chọncó code
request.setAttribute("data", "value");
response.sendRedirect("result.jsp");AAttributes are retained
BAttributes are lost
CThey are automatically sent to the next page
DThey are converted to session attributes
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "Attributes are lost". sendRedirect() trả cho trình duyệt một phản hồi chuyển hướng kèm header Location, trình duyệt tự mở một yêu cầu HTTP thứ hai tới result.jsp, và container dựng một đối tượng HttpServletRequest hoàn toàn mới cho yêu cầu đó; attribute vừa đặt chỉ sống trong đối tượng yêu cầu cũ nên trang đích không đọc được. Muốn giữ dữ liệu thì forward để ở lại trong cùng một yêu cầu, hoặc đặt vào session, hoặc nối vào query string. "Attributes are retained" là hành vi của forward qua RequestDispatcher chứ không phải của chuyển hướng. "They are automatically sent to the next page" sai vì phản hồi chuyển hướng chỉ mang địa chỉ mới, không mang theo attribute nào. "They are converted to session attributes" sai vì container không bao giờ tự nâng phạm vi của attribute, muốn lên phiên thì phải tự gọi setAttribute() trên session.
AUsing the <dropdown> element
BUsing the <list> element
CUsing the <select> element
DUsing the <options> element
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "Using the <select> element". Danh sách chọn trong form HTML được dựng bằng phần tử select, mỗi mục là một thẻ option bên trong và giá trị gửi về server là thuộc tính value của mục đang chọn, đọc ở servlet bằng request.getParameter() với tên chính là thuộc tính name của select. "Using the <dropdown> element" sai vì HTML không có phần tử nào tên dropdown, trình duyệt sẽ coi nó là thẻ lạ và không vẽ ra ô chọn nào. "Using the <list> element" cũng không tồn tại; các phần tử danh sách của HTML là ul, ol và li, chúng chỉ để trình bày nội dung và không gửi dữ liệu theo form. "Using the <options> element" sai ở dạng số nhiều: thẻ con hợp lệ bên trong select là option, và bản thân nó cũng không thay được phần tử chứa bên ngoài.
5In a standard Java web application, where is the deployment descriptor (web.xml) typically located?4 lựa chọn
A/WEB-INF
B/META-INF
C/WEB-INF/classes
DRoot directory
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "/WEB-INF". Deployment descriptor phải nằm ngay trong WEB-INF của ứng dụng web vì đây là thư mục mà container đọc để lấy cấu hình servlet, filter, listener và tham số khởi tạo, đồng thời là thư mục trình duyệt không thể yêu cầu trực tiếp nên tệp cấu hình không bị phơi ra ngoài. "/META-INF" là nơi giữ thông tin đóng gói của tệp nén, ví dụ manifest và cấu hình ngữ cảnh của một số container, chứ không phải nơi đặt descriptor của ứng dụng web. "/WEB-INF/classes" là nơi chứa lớp đã biên dịch cùng tệp tài nguyên như properties, nếu đặt descriptor ở đây container sẽ không tìm thấy. "Root directory" sai vì thư mục gốc chứa những thứ phục vụ công khai như trang JSP, HTML, ảnh và CSS, đặt tệp cấu hình ở đó là để lộ cấu hình cho người dùng tải về.
AHandling static resources like HTML and CSS
BExecuting server-side Java code (Servlets)
CManaging database connections
DRunning JavaScript code on the client-side
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "Executing server-side Java code (Servlets)". Việc chính của servlet container là quản vòng đời và chạy mã Java phía server: nạp lớp servlet, gọi init(), cấp luồng cho từng yêu cầu rồi gọi service() để phân phát sang doGet() hay doPost(), dựng đối tượng request và response, quản phiên, và gọi destroy() khi tháo ứng dụng. "Handling static resources like HTML and CSS" là việc một web server thuần cũng làm được và container có làm kèm, nhưng đó là phần phụ chứ không phải lý do container tồn tại. "Managing database connections" là việc của mã ứng dụng hoặc của một pool được khai báo riêng, container chỉ cung cấp chỗ tra cứu chứ không phải nhiệm vụ chính. "Running JavaScript code on the client-side" sai hẳn về nơi chạy: mã phía người dùng do trình duyệt thực thi, server không can dự.
7Where is the deployment descriptor located?4 lựa chọn
AThe deployment descriptor is located in the WEB-INF directory of the web application.
BThe deployment descriptor is located in the WEB-INFS directory of the web application.
CThe deployment descriptor is located in the WEBS-INF directory of the web application.
DThe deployment descriptor is located in the WEBS directory of the web application.
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "The deployment descriptor is located in the WEB-INF directory of the web application.". Tên thư mục này là một phần của khuôn dạng ứng dụng web nên viết đúng từng ký tự mới có hiệu lực: container tìm tệp cấu hình ở đúng WEB-INF, đồng thời chặn mọi yêu cầu từ trình duyệt vào thư mục đó nên cấu hình và lớp biên dịch không bị tải về. Lựa chọn ghi "WEB-INFS directory of the web application" sai vì thêm chữ S, container coi đây là một thư mục thường, cấu hình sẽ không được đọc mà lại nằm trong vùng công khai. Lựa chọn ghi "WEBS-INF directory of the web application" sai tương tự, phần đầu phải là WEB chứ không phải WEBS. Lựa chọn ghi "WEBS directory of the web application" sai vì mất hẳn phần INF, cái tên đó không có nghĩa gì với container và tệp cấu hình sẽ bị bỏ qua hoàn toàn.
8Which of the following is NOT typically configured in the web.xml file of a Java web application?4 lựa chọn
AServlet and URL mapping
BInitialization parameters
CDatabase table schema
DFilter configuration
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "Database table schema". Deployment descriptor là nơi khai những gì container cần biết để chạy ứng dụng web, còn cấu trúc bảng của cơ sở dữ liệu thuộc về chính cơ sở dữ liệu và được tạo bằng câu lệnh DDL hoặc công cụ migration; container không đọc và cũng không hiểu định nghĩa bảng. "Servlet and URL mapping" là nội dung điển hình của tệp này, cặp khai servlet và mẫu đường dẫn chính là cách container định tuyến yêu cầu. "Initialization parameters" cũng được khai ở đây, dưới dạng tham số riêng của một servlet hoặc tham số chung của toàn ứng dụng, rồi đọc lại bằng getInitParameter(). "Filter configuration" cũng thuộc tệp này: khai lớp filter và mẫu đường dẫn mà nó chặn, thứ tự khai còn quyết định thứ tự các filter nối thành chuỗi.
9What method is called in HttpServlet when using a href link to pass parameters to servlet?4 lựa chọn
A
doPost(HttpServletRequest request, HttpServletResponse response)B
doPut(HttpServletRequest request, HttpServletResponse response)C
doGet(HttpServletRequest request, HttpServletResponse response)D
doDelete(HttpServletRequest request, HttpServletResponse response)Lời giải
Mở trang câu hỏi này →Đáp án đúng: "doGet(HttpServletRequest request, HttpServletResponse response)". Một liên kết trên trang khi được bấm sẽ khiến trình duyệt phát yêu cầu GET tới đường dẫn trong thuộc tính href, tham số đi kèm nằm trong query string; container nhận yêu cầu, gọi service() và service() căn cứ vào phương thức HTTP để phân phát, nên đúng nhánh doGet() được gọi và đọc tham số bằng request.getParameter(). Lựa chọn dùng "doPost(HttpServletRequest request, HttpServletResponse response)" chỉ chạy khi form khai method là post hoặc khi mã phía người dùng tự phát yêu cầu POST, bấm liên kết không sinh ra POST. Lựa chọn dùng "doPut(HttpServletRequest request, HttpServletResponse response)" tương ứng với phương thức PUT, trình duyệt không phát PUT từ liên kết hay form thường. Lựa chọn dùng "doDelete(HttpServletRequest request" tương ứng với DELETE, cũng không phải thứ sinh ra khi bấm một liên kết, nếu không ghi đè thì container trả về lỗi phương thức không được hỗ trợ.
10Examine this servlet code:
@WebServlet("/showParams")4 lựa chọncó code
public class ShowParamsServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
ServletContext ctx = getServletContext();
PrintWriter out = response.getWriter();
Enumeration<String> paramNames = ctx.getInitParameterNames();
while(paramNames.hasMoreElements()) {
String name = paramNames.nextElement();
out.println(name + ": " + ctx.getInitParameter(name));
}
}
}If web.xml has the following entries:
<context-param>
<param-name>settingOne</param-name>
<param-value>foo</param-value>
</context-param>
<context-param>
<param-name>settingTwo</param-name>
<param-value>bar</param-value></context-param> What will the servlet output?
Afoo
bar
BsettingOne: foo
settingTwo: bar
CsettingTwo: bar
settingOne: foo
DsettingOne
settingTwo
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "settingOne: foo
settingTwo: bar". Vòng lặp đi qua Enumeration do ctx.getInitParameterNames() trả về, và mỗi lần lặp out.println() in ra chuỗi được nối từ name, dấu hai chấm kèm khoảng trắng, rồi ctx.getInitParameter(name); vì vậy mỗi dòng mang cả tên tham số lẫn giá trị của nó, lần lượt theo thứ tự hai phần tử context-param được khai trong web.xml. Lưu ý getInitParameter() ở đây gọi trên ServletContext nên đọc tham số dùng chung cho toàn ứng dụng, khác với tham số riêng của từng servlet. Lựa chọn "foo
bar" bỏ mất phần name và dấu hai chấm mà biểu thức nối chuỗi luôn in kèm. Lựa chọn "settingTwo: bar
settingOne: foo" đảo thứ tự so với thứ tự khai trong tệp cấu hình mà vòng lặp đi theo. Lựa chọn "settingOne
settingTwo" chỉ in tên, tức là kết quả của việc in name mà không gọi getInitParameter().
ASends a permanent redirect to the browser
BIncludes another JSP page's content during request processing
CTransfers request control to another resource on the server
DReturns the response to the calling servlet
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "Transfers request control to another resource on the server". Hành động chuyển tiếp của JSP chạy hoàn toàn trong một yêu cầu: container lấy RequestDispatcher của tài nguyên đích và trao quyền xử lý cho nó, trang gọi dừng phát nội dung, phần đã ghi vào bộ đệm bị bỏ, còn đối tượng request và mọi attribute trong đó vẫn giữ nguyên nên trang đích đọc lại được; trình duyệt không hay biết gì và địa chỉ trên thanh URL không đổi. "Sends a permanent redirect to the browser" sai vì chuyển hướng là một phản hồi gửi về trình duyệt để nó phát yêu cầu thứ hai, địa chỉ đổi và attribute của yêu cầu cũ mất. "Includes another JSP page's content during request processing" là việc của hành động nhúng, nó chèn kết quả của trang khác rồi trả quyền về cho trang gọi để tiếp tục, chứ không trao hẳn quyền đi. "Returns the response to the calling servlet" sai vì quyền xử lý đi một chiều sang tài nguyên đích và không quay lại trang gọi.
12Which servlet method retrieves a servlet's initialization parameter defined in the web.xml?4 lựa chọn
AgetServletConfig().getInitParameter("paramName")
BgetServletContext().getInitParameter("paramName")
CgetInitParameter("paramName")
DgetConfig().getParameter("paramName")
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "getServletConfig().getInitParameter("paramName")". Tham số khởi tạo riêng của một servlet được khai trong phần tử init-param bên trong khai báo servlet, và đối tượng giữ chúng là ServletConfig mà container truyền vào lúc gọi init(); lấy đúng đối tượng đó rồi đọc theo tên là cách nêu rõ nguồn dữ liệu. "getServletContext().getInitParameter("paramName")" đọc trên phạm vi khác: nó lấy tham số khai trong context-param dùng chung cho cả ứng dụng, nên với tham số riêng của servlet nó trả về null. "getInitParameter("paramName")" là dạng viết tắt mà lớp cha GenericServlet cung cấp bằng cách uỷ nhiệm lại cho chính ServletConfig, nên nó chỉ dùng được khi đang ở trong thân servlet và không chỉ ra được đối tượng nào đang giữ tham số. "getConfig().getParameter("paramName")" sai cả hai tên: servlet không có getConfig(), và tham số khởi tạo không đọc bằng getParameter(), đó là phương thức đọc tham số do người dùng gửi lên.
ATo store data that can be shared across multiple servlets within the same request.
BTo store data that can be shared only within the same servlet.
CTo store data that can be shared across multiple servlets in the same session.
DTo store data that can be accessed by any servlet in the application.
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "To store data that can be shared across multiple servlets within the same request.". Attribute của request là ô chứa dữ liệu gắn với đúng một đối tượng HttpServletRequest: servlet đặt dữ liệu bằng setAttribute() rồi forward sang servlet hay trang JSP khác, nơi đó đọc lại bằng getAttribute() vì vẫn là cùng một yêu cầu; hết yêu cầu thì đối tượng bị bỏ và dữ liệu mất, nhờ vậy không có chuyện dữ liệu của người này lẫn sang người khác. "To store data that can be shared only within the same servlet." bó hẹp quá mức, nếu chỉ dùng trong một servlet thì biến cục bộ đã đủ và không cần tới attribute. "To store data that can be shared across multiple servlets in the same session." là mô tả phạm vi phiên, dữ liệu ở đó sống qua nhiều yêu cầu của cùng người dùng. "To store data that can be accessed by any servlet in the application." là mô tả phạm vi ứng dụng, dữ liệu ở đó dùng chung cho mọi người dùng.
ATo define the servlet's class name
BTo specify the context path of the web application
CTo set the URL address that maps to a servlet
DTo configure filter mappings
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "To set the URL address that maps to a servlet". Trong một khai báo ánh xạ servlet, phần tử này chứa mẫu đường dẫn mà container so khớp với phần URL sau context path để quyết định yêu cầu đi vào servlet nào; mẫu có thể là đường dẫn chính xác, dạng tiền tố kết thúc bằng dấu sao, hoặc dạng theo phần mở rộng. "To define the servlet's class name" là việc của phần tử khai lớp servlet, nơi ghi tên lớp đầy đủ kèm gói để container nạp lên. "To specify the context path of the web application" sai vì context path không nằm trong tệp cấu hình của ứng dụng, nó do tên tệp triển khai hoặc cấu hình của container quyết định. "To configure filter mappings" nằm ngoài phạm vi câu hỏi: khai báo ánh xạ filter cũng dùng một phần tử cùng tên để chỉ đường dẫn bị chặn, nhưng phần tử trong ánh xạ servlet thì không cấu hình gì cho filter.
15Consider the code written on a JSP page that has the following content.
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
...
<c:set4 lựa chọncó code
var="x" value="10" /> <c:set var="y" value="5" /> ${
x + y
}What is the incorrect output produced by the JSP page above?
A15
B10+5
C510
D105
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "15". Chỉ thị taglib đã nạp thư viện lõi nên hai thẻ đặt biến tạo ra hai biến phạm vi page mang chuỗi mười và năm; khi gặp biểu thức có toán tử cộng, Expression Language không nối chuỗi mà ép cả hai toán hạng về kiểu số rồi mới tính, vì vậy con số mà trang thực sự in ra là 15 và ba giá trị còn lại là những kết quả trang này không bao giờ sinh ra. "10+5" chỉ xuất hiện nếu biểu thức bị viết thành văn bản thuần, chẳng hạn thiếu cú pháp mở biểu thức, khi đó container in nguyên văn chứ không tính. "510" là kết quả của phép ghép chuỗi với thứ tự đảo lại, điều mà toán tử cộng của Expression Language không làm. "105" là kết quả ghép chuỗi theo đúng thứ tự hai biến, cũng chỉ xảy ra nếu dùng toán tử nối chuỗi của Java trong một đoạn mã nhúng thay vì toán tử cộng của Expression Language.
16For generating an HTML page in JSP, which content type must be set using the page directive?4 lựa chọn
Atext/xml
Btext/plain
Ctext/html
Dapplication/json
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "text/html". Chỉ thị page khai contentType để JSP đặt header Content-Type trên phản hồi, và chỉ với kiểu này trình duyệt mới dựng cây DOM rồi vẽ trang kèm CSS cùng mã phía người dùng; thường viết kèm charset để dấu tiếng Việt không bị vỡ, và phải khai trước khi nội dung đầu tiên được ghi ra vì header đi trước body. "text/xml" khiến trình duyệt coi nội dung là tài liệu XML, nó sẽ kiểm cú pháp chặt và không vẽ trang như HTML, gặp thẻ không đóng là báo lỗi phân tích. "text/plain" khiến mọi thẻ hiện ra đúng dạng văn bản thô, người dùng đọc thấy cả dấu ngoặc nhọn thay vì thấy trang được vẽ. "application/json" dành cho dữ liệu trả về cho mã phía người dùng gọi nền, trình duyệt sẽ hiển thị hoặc tải về chuỗi JSON chứ không dựng trang.
A<var>
B<declare>
C<scriptlet>
D<%! %>
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "<%! %>". Khối khai báo được dịch thành thành viên của lớp servlet mà container sinh ra từ trang JSP, nên biến đặt ở đây là biến mức lớp và phương thức đặt ở đây nằm ngoài phương thức phục vụ; chính vì vậy chúng tồn tại qua nhiều yêu cầu và dùng chung cho mọi người dùng, khác với đoạn mã nhúng thường rơi vào thân phương thức phục vụ và chỉ là biến cục bộ. "<var> " không phải thẻ của JSP, trình dịch trang coi nó là thẻ lạ và gửi nguyên văn ra cho trình duyệt. "<declare> " cũng không tồn tại trong JSP, không có thư viện chuẩn nào định nghĩa thẻ này nên nó không khai báo được gì. "<scriptlet> " không phải cú pháp hợp lệ; dạng tài liệu XML của đoạn mã nhúng có tên thuộc không gian jsp, và dù viết đúng thì mã trong đoạn nhúng vẫn nằm trong thân phương thức phục vụ nên không tạo được thành viên của lớp.
A
pageContextB
requestC
applicationD
sessionLời giải
Mở trang câu hỏi này →Đáp án đúng: "application". Đối tượng ngầm định này chính là ServletContext của ứng dụng, mỗi ứng dụng web chỉ có một, nên dữ liệu đặt vào bằng setAttribute() sống suốt thời gian ứng dụng chạy và mọi servlet cùng mọi trang JSP của mọi người dùng đều đọc được; cũng qua nó mà trang đọc tham số khai chung và ghi log của ứng dụng. "pageContext" chỉ gói ngữ cảnh của riêng trang đang chạy và là đường đi tới các phạm vi khác, bản thân nó hết hiệu lực khi trang xử lý xong nên không giữ được dữ liệu toàn ứng dụng. "request" gắn với một yêu cầu, dữ liệu đặt trong đó mất ngay khi phản hồi được trả về. "session" gắn với một người dùng cụ thể và sống qua nhiều yêu cầu, nhưng dữ liệu của người này không hiện ra cho người khác nên không phải chỗ giữ thông tin dùng chung cho cả ứng dụng.
A
paramsB
requestC
inputD
getParametersLời giải
Mở trang câu hỏi này →Đáp án đúng: "request". Tham số gửi tới trang, dù nằm trong query string của một liên kết hay trong body của form gửi theo POST, đều do container gom vào đối tượng yêu cầu; trong JSP đối tượng đó lộ ra dưới tên request và đọc bằng getParameter() cho một giá trị hoặc getParameterValues() cho nhiều giá trị cùng tên, mọi giá trị trả về đều là chuỗi nên muốn số thì phải tự chuyển kiểu. "params" không phải đối tượng ngầm định của JSP; trong Expression Language có một map tên gần giống để tra tham số, nhưng đó là biến của biểu thức chứ không phải đối tượng ngầm định như câu hỏi nói tới. "input" không tồn tại trong JSP, đây là tên thẻ nhập liệu bên HTML. "getParameters" là tên nghe như một phương thức chứ không phải một đối tượng, và cũng không có phương thức nào tên như vậy để lấy tham số.
AJSTL improves readability over scriptlets
BJSTL completely replaces servlets for business logic
CJSTL requires importing core and optional tag libraries
DJSTL provides tags for iteration, conditionals, and internationalization
Lời giải
Mở trang câu hỏi này →Đáp án đúng: "JSTL completely replaces servlets for business logic". Thư viện thẻ chuẩn chỉ là lớp trình bày: nó thay cho các đoạn mã Java nhúng trong trang để lặp, rẽ nhánh, định dạng và quốc tế hoá, chứ không nhận yêu cầu, không điều phối luồng xử lý, không gọi lớp truy cập dữ liệu hay quản phiên; những việc đó vẫn thuộc servlet, nên mệnh đề này là mệnh đề không đứng được. "JSTL improves readability over scriptlets" là nhận định đúng, thẻ có cấu trúc rõ ràng giúp trang dễ đọc và dễ bảo trì hơn mã Java chen trong HTML. "JSTL requires importing core and optional tag libraries" cũng đúng, phải có chỉ thị taglib khai không gian tên và tiền tố thì trình dịch trang mới hiểu thẻ, thiếu nó thì thẻ bị trả nguyên văn ra trình duyệt. "JSTL provides tags for iteration, conditionals, and internationalization" đúng, đó chính là các nhóm thẻ mà thư viện cung cấp.