Đáp án đúng: "Accepting single-line text input". Thẻ nhập với kiểu văn bản vẽ ra một ô một dòng để người dùng gõ chuỗi; khi biểu mẫu được gửi, trình duyệt ghép giá trị với tên của ô thành một cặp tham số, và phía servlet đọc bằng getParameter với đúng tên đó, nên thiếu tên là mất dữ liệu. Lựa chọn "Displaying a multiline text area" là việc của thẻ vùng văn bản, thứ có thẻ mở và thẻ đóng riêng vì nội dung ban đầu nằm giữa chúng. Lựa chọn "Creating a checkbox" cần đổi kiểu của ô, và cách đọc cũng khác vì ô không được tích thì không gửi tham số nào lên. Lựa chọn "Selecting items from a dropdown list" là việc của thẻ danh sách chọn với các mục bên trong, và nó chỉ gửi lên giá trị của mục đang được chọn.
AIndicates that the requested resource is not available.
BIndicates that the request requires HTTP authentication.
CIndicates an error inside the HTTP server which prevented it from fulfilling the request.
DIndicates that the HTTP server is temporarily overloaded, and unable to handle the request.
Lời giải
Đáp án đúng: "Indicates that the request requires HTTP authentication.". Mã 401 thuộc nhóm 4xx, tức lỗi phía người gọi: máy chủ hiểu yêu cầu nhưng tài nguyên đòi xác thực, nên phản hồi kèm header yêu cầu khai danh tính để trình duyệt hỏi tên và mật khẩu; trong Java web thường gặp mã này khi servlet gọi sendError với hằng số báo chưa xác thực, hoặc khi một ràng buộc bảo mật khai trong web.xml chặn tài nguyên mà người dùng chưa đăng nhập. "Indicates that the requested resource is not available." mô tả mã 404, nghĩa là đường dẫn yêu cầu không tồn tại trên máy chủ, khác hẳn chuyện thiếu danh tính. "Indicates an error inside the HTTP server which prevented it from fulfilling the request." mô tả mã 500, lỗi nội tại của máy chủ, thường do servlet ném ngoại lệ không bắt được nên không soạn nổi phản hồi. "Indicates that the HTTP server is temporarily overloaded, and unable to handle the request." mô tả mã 503, máy chủ quá tải hoặc đang bảo trì nên tạm thời không nhận yêu cầu, và lỗi này không liên quan tới quyền truy cập.
Đáp án đúng: "PATCH". Phương thức này được định nghĩa để gửi lên một mô tả các thay đổi cần áp vào tài nguyên, nên máy khách chỉ truyền những trường muốn sửa thay vì cả bản ghi; đó đúng là nghĩa cập nhật một phần mà câu hỏi nhắm tới. Lựa chọn "POST" là phương thức mở, thường dùng để tạo tài nguyên mới hoặc đẩy dữ liệu cho máy chủ xử lý theo cách riêng, nó không mang ngữ nghĩa sửa một phần và cũng không bảo đảm gọi lại nhiều lần cho cùng kết quả. Lựa chọn "GET" là phương thức an toàn, chỉ để đọc, không được phép làm biến đổi trạng thái tài nguyên trên máy chủ. Lựa chọn "DELETE" dùng để xoá hẳn tài nguyên chứ không sửa nội dung của nó. Nếu muốn ghi đè toàn bộ biểu diễn của tài nguyên thì mới dùng PUT, và chính sự phân biệt giữa thay toàn bộ với sửa một phần là lý do PATCH ra đời.
Đáp án đúng: "Hosting and executing servlets". Servlet container là phần chạy bên trong máy chủ web, chịu trách nhiệm nạp lớp servlet, tạo đối tượng, gọi init() một lần để chuẩn bị, gọi service() cho từng yêu cầu rồi gọi destroy() khi tháo ứng dụng; nó cũng dựng sẵn cặp request với response, đọc ánh xạ URL trong mô tả triển khai và quản lý phiên. Lựa chọn "Managing database transactions" nằm ngoài phạm vi ấy, vì giao dịch do mã JDBC hoặc tầng truy cập dữ liệu tự điều khiển. Lựa chọn "Serving static content" chỉ là việc phụ, phần tĩnh thường do máy chủ web hoặc servlet mặc định trả về và không phải lý do container tồn tại. Lựa chọn "Handling client-side scripting" càng lạc chỗ, vì mã phía máy khách chạy trong trình duyệt, container không hề thực thi nó.
Đá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.
AConnect → Create Statement → Execute Query → Process Result
BCreate Statement → Connect → Execute Query → Process Result
CConnect → Execute Query → Create Statement → Process Result
DConnect → Process Result → Execute Query → Create Statement
Lời giải
Đáp án đúng: "Connect → Create Statement → Execute Query → Process Result". Thứ tự này đi đúng chuỗi phụ thuộc của JDBC: trước hết DriverManager.getConnection() mở một Connection, từ Connection mới tạo được Statement hoặc PreparedStatement, có đối tượng câu lệnh rồi mới gọi được executeQuery(), và chỉ khi câu lệnh chạy xong mới có ResultSet để duyệt. Lựa chọn "Create Statement → Connect → Execute Query → Process Result" sai vì createStatement() chính là phương thức của Connection, chưa kết nối thì chưa có gì tạo câu lệnh. Lựa chọn "Connect → Execute Query → Create Statement → Process Result" sai vì không có đối tượng câu lệnh thì chẳng có gì để thực thi truy vấn. Lựa chọn "Connect → Process Result → Execute Query → Create Statement" đảo ngược hẳn, đi xử lý kết quả trước khi truy vấn chạy nên không có dữ liệu nào tồn tại.
BSpecifying how URLs should be routed to specific servlets
CManaging session attributes in servlets
DDefining request parameters for the servlets
Lời giải
Đáp án đúng: "Specifying how URLs should be routed to specific servlets". Thẻ servlet-mapping ghép một tên servlet đã khai báo với một hay nhiều url-pattern, nhờ đó container biết yêu cầu tới đường dẫn nào thì giao cho lớp nào xử lý; thiếu nó thì servlet vẫn tồn tại nhưng không có cửa vào từ phía máy khách. Lựa chọn "Configuring error pages for specific servlets" là việc của thẻ error-page, nơi khai mã lỗi hoặc loại ngoại lệ cùng trang hiển thị tương ứng. Lựa chọn "Managing session attributes in servlets" thuộc mã chạy trong servlet qua HttpSession, mô tả triển khai chỉ cấu hình được thời gian sống của phiên. Lựa chọn "Defining request parameters for the servlets" cũng không đúng, tham số yêu cầu do máy khách gửi lên, còn tham số khai sẵn cho servlet thì nằm ở init-param.
Đáp án đúng: "context-param". Thẻ này nằm trực tiếp trong web-app và khai báo cặp param-name với param-value ở mức toàn ứng dụng; mọi servlet, mọi trang JSP và cả filter đều đọc được qua getServletContext().getInitParameter(), vì nó gắn vào ServletContext dùng chung. Lựa chọn "global-settings" không phải thẻ hợp lệ trong lược đồ của mô tả triển khai, container sẽ báo lỗi khi nạp ứng dụng. Lựa chọn "app-parameters" cũng là tên tự đặt, không có trong đặc tả servlet nên không được nhận. Lựa chọn "servlet-config" nhầm với giao diện ServletConfig trong mã Java: cấu hình riêng của một servlet được khai bằng init-param đặt trong thẻ servlet và chỉ chính servlet đó đọc được, nên dù có tên ấy thì phạm vi cũng chỉ là một servlet chứ không toàn ứng dụng.
Đáp án đúng: "<init-param> ". Thẻ này đặt bên trong thẻ servlet của mô tả triển khai, mang một cặp param-name và param-value mà servlet đọc lại bằng getServletConfig().getInitParameter() hoặc gọi getInitParameter() ngay trong init(); nhờ vậy những giá trị như tên tệp cấu hình hay chuỗi kết nối không phải viết cứng trong mã. Lựa chọn "<param> " không tồn tại ở mức này, chữ param chỉ xuất hiện dưới dạng param-name và param-value, hoặc trong thẻ jsp:param của hành động chuẩn. Lựa chọn "<configuration> " không thuộc lược đồ web.xml của đặc tả servlet, đó là tên quen thuộc ở các tệp cấu hình khung khác. Lựa chọn "<servlet-param> " là tên đặt theo cảm giác, container không nhận ra và ứng dụng sẽ không triển khai được.
Đáp án đúng: "Both A, B and C". Câu hỏi hỏi công nghệ nào giúp quản lý phiên trong Java web, và cả ba thứ được liệt kê đều là mảnh của cùng một cơ chế: máy chủ giữ dữ liệu phiên theo một mã phiên, còn mã phiên ấy phải được chuyển qua lại giữa hai bên, bằng cookie hoặc bằng cách nhúng vào đường dẫn. "Cookies" đúng là phương tiện mang mã phiên, nhưng nêu riêng nó thì thiếu: nó chỉ là chỗ chứa mã chứ không phải nơi lưu dữ liệu phiên, và khi trình duyệt chặn nó thì vẫn còn đường khác. "HttpSession" là API phía máy chủ giữ dữ liệu theo từng người dùng, song nó vẫn phải dựa vào mã phiên do client gửi lên mới biết lấy đúng phiên nào, nên một mình nó cũng chưa trả lời đủ. "URL Rewriting" là cách dự phòng khi không có cookie, làm bằng phương thức mã hoá URL để nối mã phiên vào đường dẫn, và bản thân nó không phải toàn bộ cách quản lý phiên.
public void service(ServletRequest request, ServletResponse response){//…}
". Hợp đồng của giao diện Servlet quy định service() nhận đúng hai tham số, một ServletRequest mang dữ liệu yêu cầu và một ServletResponse để ghi kết quả, vì container luôn truyền cả cặp này vào mỗi khi có yêu cầu tới; khai báo lệch chữ ký thì phương thức chỉ còn là một method thường của lớp, container không bao giờ gọi. Lựa chọn "
Lời giải
public void service(){//…}
" không có tham số nên vừa không nhận được dữ liệu yêu cầu vừa không có đường ghi trả về. Lựa chọn "
Lời giải
public void service(ServletRequest request){//…}
" thiếu đối tượng phản hồi, đọc được tham số nhưng không thể sinh nội dung cho máy khách. Lựa chọn "
Lời giải
public void service(ServletResponse response){//…}
" thì ngược lại, ghi ra được nhưng mất hẳn phần đọc yêu cầu, và cả hai cách này đều không phải phương thức ghi đè hợp lệ.
Đáp án đúng: "response.sendRedirect("url"); ". Chuyển hướng là việc của đối tượng phản hồi: phương thức này đặt mã trạng thái chuyển hướng cùng tiêu đề Location rồi gửi về trình duyệt, trình duyệt tự phát một yêu cầu mới tới địa chỉ đó nên thanh địa chỉ đổi và dữ liệu trong phạm vi request cũ bị mất. Lựa chọn "request.sendRedirect("url"); " gọi sai đối tượng, giao diện HttpServletRequest không có phương thức này mà chỉ có getRequestDispatcher(). Lựa chọn "redirect("url");" là lời gọi tự do không thuộc API servlet, lớp HttpServlet không cung cấp tên như vậy. Lựa chọn "forward("url");" vừa sai chỗ gọi vì forward là phương thức của RequestDispatcher, vừa sai bản chất vì forward xử lý tiếp ngay trong cùng một lượt yêu cầu ở phía máy chủ nên địa chỉ không đổi.
Đáp án đúng: "service()". Trong vòng đời servlet, container nạp lớp rồi gọi init() đúng một lần để chuẩn bị, sau đó với mỗi yêu cầu của máy khách nó gọi service() trên cùng một đối tượng servlet, truyền vào request và response của lượt đó; ở HttpServlet, service() đọc phương thức HTTP rồi điều phối sang doGet(), doPost() và các phương thức tương ứng. Lựa chọn "destroy()" chỉ chạy một lần khi container tháo servlet khỏi bộ nhớ, thường lúc dừng hoặc nạp lại ứng dụng, nên không liên quan tới từng yêu cầu. Lựa chọn "init()" cũng chỉ chạy một lần trước khi servlet phục vụ yêu cầu đầu tiên, đó là chỗ mở tài nguyên dùng lâu. Lựa chọn "start()" không thuộc giao diện Servlet, nó gợi nhớ tới luồng chứ không có trong hợp đồng mà container gọi.
Đáp án đúng: "To handle HTTP requests and responses". HttpServlet là lớp trừu tượng chuyên biệt hoá GenericServlet cho giao thức HTTP: nó hiện thực service() để đọc phương thức của yêu cầu rồi gọi doGet(), doPost(), doPut() hay doDelete() tương ứng, và làm việc với HttpServletRequest cùng HttpServletResponse để đọc tham số, tiêu đề, cookie và ghi nội dung trả về. Lựa chọn "To connect to databases" không phải nhiệm vụ của nó, phần kết nối do JDBC đảm nhiệm và nên tách sang tầng riêng. Lựa chọn "To manage session tracking" là việc container làm qua HttpSession, servlet chỉ gọi getSession() để dùng. Lựa chọn "Request forwarding is slower than a redirect." không trả lời câu được hỏi, nó là nhận định hiệu năng và còn ngược thực tế vì forward diễn ra trong máy chủ còn redirect cần thêm một vòng đi về của trình duyệt.
Đáp án đúng: "<url-pattern> ". Đây là thẻ ghi mẫu đường dẫn, đặt trong servlet-mapping bên cạnh servlet-name, và chính nó quyết định yêu cầu tới địa chỉ nào sẽ được giao cho servlet đã khai bá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 phần mở rộng. Lựa chọn "<servlet-name> " chỉ là nhãn logic dùng để nối khai báo servlet với ánh xạ, bản thân nó không chứa địa chỉ nào. Lựa chọn "<servlet-class> " cho biết tên lớp Java đầy đủ để container nạp, cũng không nói gì về URL. Lựa chọn "<mapping> " không tồn tại trong lược đồ mô tả triển khai; thẻ đúng là servlet-mapping, và nó chỉ là khung bọc chứa servlet-name với url-pattern chứ bản thân cũng không phải nơi ghi mẫu đường dẫn.
ATo include another JSP page during the translation phase.
BTo import a Java class into the JSP page.
CTo forward the request to another resource.
DTo include another JSP page during the request processing phase.
Lời giải
Đáp án đúng: "To include another JSP page during the translation phase.". Chỉ thị include được bộ dịch xử lý trước khi sinh mã: nội dung tệp được chỉ tới bị chèn thẳng vào nguồn của trang chủ rồi cả khối mới được dịch thành một lớp servlet duy nhất, nên hai trang chia sẻ biến khai báo và thay đổi ở tệp con có thể cần dịch lại trang cha. Lựa chọn "To include another JSP page during the request processing phase." mô tả hành động chuẩn jsp:include, thứ chạy lúc phục vụ yêu cầu và gọi tệp con như một tài nguyên riêng qua RequestDispatcher. Lựa chọn "To import a Java class into the JSP page." là việc của chỉ thị page với thuộc tính import. Lựa chọn "To forward the request to another resource." ứng với jsp:forward, tức chuyển hẳn quyền sinh nội dung sang nơi khác chứ không ghép thêm vào trang hiện tại.
AFiles within /WEB-INF are automatically encrypted by the web container, providing an extra layer of data protection.
BFiles within /WEB-INF are not directly accessible through a URL, enhancing the security of sensitive code and resources.
CFiles within /WEB-INF are only accessible by users with administrative privileges, preventing unauthorised modifications.
DFiles within /WEB-INF are compiled and cached more aggressively by the web container, leading to performance improvements.
Lời giải
Đáp án đúng: "Files within /WEB-INF are not directly accessible through a URL, enhancing the security of sensitive code and resources.". Container coi /WEB-INF là vùng riêng của ứng dụng: không mẫu URL nào trỏ tới được, máy khách gõ thẳng đường dẫn thì bị từ chối, chỉ mã phía máy chủ mới chạm tới qua RequestDispatcher hoặc getResourceAsStream. Nhờ vậy các mảnh JSP chỉ hiển thị sau khi controller đã kiểm tra quyền, không ai xem được chúng rời rạc. Lựa chọn nói các tệp ở đó "automatically encrypted by the web container" là không có cơ sở, nội dung vẫn nằm nguyên dạng trên đĩa. Lựa chọn nói chúng "only accessible by users with administrative privileges" sai cơ chế, vì rào ở đây dựng theo đường dẫn chứ không theo vai trò người dùng. Lựa chọn nói chúng được "compiled and cached more aggressively by the web container" nhầm sang hiệu năng, trong khi vị trí thư mục không đổi cách dịch hay cách lưu đệm của trang.
Đáp án đúng: "Yes". Biểu thức dùng toán tử điều kiện của EL: phần điều kiện 2 lớn hơn 1 được tính trước, EL ép hai toán hạng về số rồi so sánh, kết quả là true nên giá trị của cả biểu thức là nhánh đứng trước dấu hai chấm, và chuỗi ấy được ghi thẳng ra nội dung trang. Lựa chọn "No" chỉ được chọn khi điều kiện cho false, ở đây không xảy ra vì 2 thực sự lớn hơn 1. Lựa chọn "2" lẫn toán hạng với kết quả: số đó chỉ tham gia phép so sánh, bản thân nó không phải giá trị trả về của toán tử điều kiện. Lựa chọn "Error" cũng không đúng, vì cú pháp hoàn toàn hợp lệ: EL cho phép viết chuỗi bằng nháy đơn và có toán tử điều kiện, nên trang dịch rồi chạy bình thường mà không sinh ngoại lệ nào.
Đá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.
Đáp án đúng: "request.getParameter()". Dữ liệu biểu mẫu do client gửi lên nằm trong đối tượng yêu cầu, nên trong JSP ta đọc qua đối tượng ẩn request kiểu HttpServletRequest: phương thức này nhận tên trường theo thuộc tính name và trả về một chuỗi, hoặc null nếu trường đó không được gửi. "response.getParameter()" không tồn tại vì đối tượng phản hồi chỉ dùng để tạo dữ liệu trả về client, qua luồng ghi hay việc đặt kiểu nội dung, nó không mang tham số đi vào. "request.getValue()" cũng không có trong API; thứ gần với cái tên đó trong đối tượng yêu cầu là getAttribute, nhưng attribute là dữ liệu do chính máy chủ đặt vào để chuyển giữa servlet và trang, không phải dữ liệu biểu mẫu. "response.getValue()" sai cả hai điểm: vừa gọi trên đối tượng phản hồi, vừa gọi một phương thức không hề tồn tại.
