Tất cả câu hỏi

Đáp án đúng: "Checks if the username parameter has a value". Trong EL, param là một map ẩn ánh xạ tên tham số của yêu cầu sang giá trị đầu tiên của nó; toán tử empty trả về true khi giá trị là null, chuỗi rỗng hoặc tập rỗng, còn toán tử not đảo kết quả lại, nên cả biểu thức cho ra một giá trị luận lý: true khi tham số có mặt và không rỗng. Vì vậy nó hay nằm trong thuộc tính điều kiện của thẻ kiểm tra để quyết định có hiển thị khối bên trong hay không. "Returns true if username is empty" là nghĩa của biểu thức khi bỏ mất toán tử not, tức đúng ngược lại. "Returns the value of username" là việc của biểu thức chỉ gồm map param và tên tham số, không có hai toán tử kia. "Always returns username" sai vì kết quả luôn là true hoặc false, không bao giờ là tên hay giá trị của tham số. Lựa chọn nói rằng biểu thức kiểm tra xem tham số "has a value then return its value" cũng sai: EL không có nhánh ngầm vừa kiểm vừa trả, muốn thế phải viết thêm toán tử ba ngôi.

Đáp án đúng: "There is a syntax-error because missing the JSTL library.". Trang có dùng thẻ đặt biến của thư viện thẻ chuẩn nhưng không hề có chỉ thị taglib khai địa chỉ thư viện lõi cùng tiền tố c, nên ở pha dịch container không biết tiền tố đó thuộc thư viện nào và trang không dịch nổi; lỗi xảy ra trước khi có bất cứ dòng kết quả nào. "Throw an exception because the code can not use EL in this sitution." sai vì bản thân biểu thức cộng hai thuộc tính giá của hai bean phạm vi trang là biểu thức hợp lệ, EL dùng được bình thường ở đây. "Result=220" là con số sẽ hiện ra nếu trang khai đủ thư viện, bởi hai giá trị đặt vào là 100 và 120. "Result=0" không thể xảy ra vì không có phép gán nào cho tổng bằng không. "Result=null" cũng không, bởi EL in một giá trị không tìm thấy thành chuỗi rỗng chứ không in ra chữ null. "Result="" ( a empty string)" thì gần với cách EL ứng xử khi biến chưa có, nhưng ở đây trang dừng ngay tại pha dịch nên không có đầu ra nào để bàn.

Đáp án đúng: "setAttribute()". Đặc tả Servlet dùng chung một tên phương thức nhận một chuỗi khoá cùng một đối tượng giá trị cho cả bốn phạm vi dữ liệu, nên chính đối tượng mà ta gọi nó mới quyết định tầm sống: gọi trên ngữ cảnh ứng dụng thì dữ liệu dùng chung cho mọi người tới khi ứng dụng dừng, gọi trên phiên thì riêng từng người, gọi trên yêu cầu thì chỉ sống trong một lượt phục vụ; đọc lại bằng getAttribute và xoá bằng removeAttribute. "setContextAttribute()" không tồn tại trong API, tên phương thức không lặp lại chữ ngữ cảnh vì kiểu của đối tượng đã nói điều đó rồi. "addAttribute()" cũng không có trong đặc tả Servlet; tên này quen thuộc ở thư viện khác chứ không phải ở đây. "addContextAttribute()" là tên bịa gộp cả hai lỗi trên, vừa sai động từ vừa thêm chữ ngữ cảnh thừa.

Đáp án đúng: "ServletContext stores data for the entire application, while HttpSession only stores data for each user". Mỗi ứng dụng web chỉ có một ngữ cảnh, do container tạo khi ứng dụng khởi động và huỷ khi ứng dụng bị gỡ hoặc máy chủ tắt, nên dữ liệu đặt vào đó dùng chung cho mọi người truy cập; còn phiên có một thực thể cho mỗi người dùng, sinh ra khi lần đầu gọi lấy phiên và mất khi bị huỷ tường minh hoặc hết khoảng chờ không hoạt động, nên dữ liệu trong đó riêng của từng người. "ServletContext is created each time a user accesses, HttpSession is created each request" đảo lộn cả hai: ngữ cảnh không tạo lại theo mỗi lượt truy cập, và phiên không sinh mới theo từng yêu cầu, nếu vậy thì chẳng giữ được trạng thái nào. "ServletContext is destroyed when the session times out, while HttpSession is destroyed when the server shuts down" cũng đổi chỗ vòng đời của hai thứ, vì hết thời gian chờ là chuyện của phiên còn tắt máy chủ là chuyện của ngữ cảnh. "There is no difference" sai vì hai thứ khác nhau cả về phạm vi dữ liệu, số lượng thực thể lẫn thời điểm sinh và huỷ.

Đáp án đúng: "Advisable to reduce the frequency of database queries, hence optimizing performance.". Dữ liệu đặt trong phiên nằm ở bộ nhớ phía máy chủ, client chỉ giữ mã phiên, nên sau khi đăng nhập một lần ta đọc vai trò và quyền từ phiên cho mọi yêu cầu sau mà không phải hỏi lại cơ sở dữ liệu; với ứng dụng mà trang nào cũng cần kiểm quyền thì số truy vấn tiết kiệm được rất đáng kể, và đó đúng là hệ quả câu hỏi nhắm tới. "This method is both secure and efficient, providing immediate retrieval of authorization details" khẳng định quá mạnh ở chữ an toàn: cách làm này vẫn phải chống việc chiếm mã phiên và vẫn phải làm mới khi quyền thay đổi, nên gọi nó vừa an toàn vừa hiệu quả là không chính xác. Lựa chọn cho rằng cách này "unsafe because there is a risk that someone could change the session information" lại mô tả sai cơ chế: nội dung phiên không nằm phía client nên người dùng không sửa trực tiếp được, khác hẳn dữ liệu đặt trong cookie hay trường ẩn. "There are no identified disadvantages; this technique is widely endorsed for managing access controls" sai vì nhược điểm có thật và dễ chỉ ra: quyền bị thu hồi trong cơ sở dữ liệu không tự phản ánh vào phiên đang mở, và dữ liệu phiên chiếm bộ nhớ nên phải nhân bản khi chạy nhiều máy.

Đáp án đúng: "Session ID". Phía máy chủ, mỗi phiên là một bản ghi trong bảng phiên của container và khoá tra cứu chính là mã phiên: client gửi mã ấy kèm mỗi yêu cầu, container đối chiếu rồi trả về đúng đối tượng phiên, đó là việc xảy ra bên trong lời gọi lấy phiên. "IP address of the client" không dùng được làm khoá vì nhiều máy sau một bộ định tuyến chia nhau cùng một địa chỉ, lại đổi khi người dùng chuyển mạng, nên vừa không duy nhất vừa không bền. "User-agent string" càng không, bởi hàng loạt máy cùng cấu hình khai báo chuỗi giống nhau, mà chuỗi này do client tự gửi nên sửa lúc nào cũng được. "Server-generated random token" chỉ nói về cách sinh ra giá trị, vì bản thân mã phiên vốn là một giá trị ngẫu nhiên do máy chủ tạo; nó không chỉ ra một cơ chế nhận diện nào khác, và thứ container dùng để tra phiên vẫn là mã phiên.

Đáp án đúng: "Distribute user-generated content across multiple tiers, applying appropriate security measures at each level.". Nguyên tắc nhiều tầng là mỗi tầng tự coi dữ liệu đến từ tầng ngoài là chưa đáng tin và tự đặt chốt kiểm riêng: tầng hiển thị lọc rồi thoát ký tự để nội dung do người dùng gửi không chạy được như mã, tầng nghiệp vụ kiểm quyền và kiểm quy tắc trước khi chấp nhận thao tác, tầng dữ liệu dùng câu lệnh tham số hoá cùng tài khoản kết nối chỉ đủ quyền tối thiểu; nhờ nhiều lớp mà một chốt bị lọt thì vẫn còn chốt sau. "Place all user-generated content in a single tier to simplify security protocols." sai vì gom hết vào một tầng tạo ra đúng một điểm vỡ, lọt một lần là mất tất cả. "Centralize all business logic in the presentation tier to control access to user-generated content." sai vì đưa nghiệp vụ lên tầng hiển thị khiến mọi kiểm soát nằm ở chỗ gần người dùng nhất và có thể bị bỏ qua khi ai đó gọi thẳng tầng dưới. "Utilize a flat architecture to avoid the complexity of multi-tier security." sai vì kiến trúc phẳng xoá luôn các ranh giới tin cậy, tức bỏ đi chính thứ tạo nên chiều sâu phòng thủ.

Đáp án đúng: "It would improve testability by allowing the components to be tested in isolation". MVC2 dồn việc điều phối vào một servlet trung tâm và đẩy nghiệp vụ xuống các lớp Java thuần, nên mỗi phần kiểm thử được một mình: lớp mô hình và lớp truy cập dữ liệu chạy trong bộ kiểm thử đơn vị mà không cần container, bộ điều khiển thử bằng đối tượng yêu cầu và phản hồi giả lập, còn trang hiển thị chỉ còn việc đọc dữ liệu đã chuẩn bị sẵn nên gần như không còn logic phải kiểm. "It would make the application harder to test due to increased complexity" sai vì cái tăng thêm là số lớp, không phải độ rối của từng đơn vị; mỗi đơn vị nhỏ và ít phụ thuộc thì càng dễ kiểm. "It would have no impact on testability as the architecture doesn't influence testing approaches" sai vì kiến trúc quyết định đúng cái ranh giới kiểm thử: khi nghiệp vụ nằm lẫn trong trang hiển thị thì buộc phải chạy cả máy chủ mới thử nổi. "It would reduce testability due to the tight coupling between view and controller." sai ngay ở tiền đề, chính MVC2 làm giảm ràng buộc chặt giữa hiển thị và điều khiển bằng cách cho chúng chỉ trao đổi qua dữ liệu đặt trong phạm vi yêu cầu.

Đáp án đúng: "By allowing separate scaling of user interface and data processing components.". MVC chia ứng dụng thành ba phần có trách nhiệm rõ ràng và ranh giới gọi nhau hẹp, nên từng phần triển khai rồi nhân bản độc lập: phần hiển thị cùng bộ điều khiển chạy trên nhiều máy phía trước, trong khi phần xử lý dữ liệu đặt riêng và được tối ưu theo cách khác; đổi trang hiển thị cũng không buộc sửa lớp truy cập dữ liệu và ngược lại. "By minimizing the amount of data stored in a database." lạc đề vì MVC là cách tổ chức mã, nó không hứa hẹn gì về lượng dữ liệu lưu trong cơ sở dữ liệu. "By consolidating all logic into a single component" chính là mô tả của kiểu dồn mọi thứ vào một chỗ, đúng cái mà MVC muốn tránh, và nó làm việc mở rộng khó hơn chứ không dễ hơn. "By enforcing stateful interactions between components." sai vì MVC không bắt buộc giữ trạng thái giữa các thành phần; muốn mở rộng theo chiều ngang thì càng nên giữ ít trạng thái trên máy chủ.

Đáp án đúng: "HttpSession is valid even after the browser is closed and reopened". Mã phiên được gửi qua một cookie phiên không khai thời hạn sống, nên trình duyệt xoá nó khi đóng; lần mở lại người dùng không còn gửi mã cũ, container không tìm thấy phiên nào khớp và cấp một phiên mới, còn bản ghi cũ nằm trên máy chủ cho tới khi hết khoảng chờ không hoạt động rồi bị dọn. Vì vậy phát biểu rằng phiên vẫn còn hiệu lực sau khi đóng rồi mở lại trình duyệt chính là phát biểu sai mà câu hỏi tìm. "HttpSession allows storing user data across multiple HTTP requests" là phát biểu đúng, bởi giữ dữ liệu xuyên nhiều yêu cầu chính là lý do tồn tại của phiên. "Session IDs are often stored in cookies or appended to URLs" cũng đúng, đó là hai cách mang mã phiên đi theo khi client gọi lại. "HttpSession can be retrieved via request.getSession(true)" đúng nữa: gọi lấy phiên với tham số true nghĩa là trả về phiên hiện có, hoặc tạo mới nếu người dùng chưa có phiên nào.

Đáp án đúng: "It requires each transaction to be committed or rolled back manually.". Mặc định kết nối ở chế độ tự chốt, mỗi câu lệnh là một giao dịch đóng ngay sau khi chạy xong. Đặt cờ ấy thành false mở một giao dịch kéo dài: các câu lệnh sau đó chỉ ghi tạm cho tới khi gọi commit để chốt hoặc rollback để huỷ, nhờ vậy nhiều câu lệnh trở thành một đơn vị nguyên tử, ví dụ trừ tiền tài khoản này rồi cộng cho tài khoản kia. "It disables the transaction management feature." nói ngược: thao tác này không tắt mà chính là mở quản lý giao dịch một cách tường minh. "It turns on auto-commit mode for each SQL statement." sai vì tham số false tắt chế độ tự chốt, muốn bật lại phải truyền true. "It automatically rolls back transactions if an error occurs." sai vì không hề có việc tự huỷ khi gặp lỗi; chương trình phải tự gọi rollback trong khối bắt ngoại lệ, bỏ qua thì phần đã làm có thể bị chốt hoặc bị bỏ dở tuỳ cách đóng kết nối.

Đáp án đúng: "Use the getConnection() method of the DriverManager class". Trình tự thông thường là nạp driver rồi gọi phương thức tĩnh này với chuỗi địa chỉ dạng jdbc kèm tên người dùng và mật khẩu; lớp quản lý driver hỏi lần lượt các driver đã đăng ký xem ai hiểu chuỗi địa chỉ đó và trả về đối tượng kết nối do driver ấy tạo, rồi từ đối tượng kết nối ta mới tạo được câu lệnh để chạy SQL. "Call the createConnection() method of the ConnectionFactory class" sai vì trong JDBC chuẩn không có lớp nào mang tên đó, đây là tên nghe giống khuôn mẫu nhà máy nhưng không tồn tại. "Instantiate a new Connection object directly" sai vì kết nối là một giao diện, không thể dựng trực tiếp bằng toán tử tạo đối tượng; thực thể cụ thể luôn do driver cung cấp. "Execute a SQL query to establish a connection dynamically" sai ở thứ tự nhân quả: muốn gửi được một câu SQL thì phải có kết nối trước đã, nên không thể dùng chính SQL để mở kết nối.

Đáp án đúng: "context.xml". Khi triển khai, tham số kết nối cơ sở dữ liệu thường được khai thành một tài nguyên trong tệp này: thẻ mô tả ngữ cảnh của ứng dụng chứa khai báo tài nguyên kiểu DataSource với địa chỉ, tên người dùng, mật khẩu và thông số pool, rồi mã Java tra tài nguyên đó qua JNDI; nhờ vậy đổi máy chủ hay đổi mật khẩu chỉ cần sửa tệp cấu hình chứ không biên dịch lại ứng dụng. "web.xml" là bộ mô tả triển khai, nơi khai servlet, filter, listener và trang chào; nó có thể khai một tham chiếu tới tài nguyên, nhưng giá trị kết nối thật của từng môi trường không nằm ở đây. "index.html" chỉ là một trang tĩnh, không mang cấu hình nào. "META-INF/MANIFEST.MF" là tệp kê khai siêu dữ liệu của gói, dùng khai phiên bản hay classpath, không phải nơi đặt thông tin kết nối.

Đáp án đúng: "Both A and B are correct". Câu lệnh tham số hoá được gửi tới hệ quản trị dưới dạng khuôn có dấu hỏi làm chỗ trống, nên kế hoạch thực thi được chuẩn bị một lần rồi dùng lại cho nhiều lượt chạy; đồng thời giá trị truyền qua các phương thức đặt tham số được driver chuyển đi như dữ liệu chứ không ghép vào chuỗi SQL, nên kẻ tấn công không chèn thêm được mệnh đề nào. Hai lợi ích vì vậy cùng xuất hiện. "Better performance with repeated queries" đúng nhưng chỉ nêu một nửa, nó bỏ qua lợi ích an toàn, trong khi đó mới là lý do quan trọng nhất khiến người ta rời Statement. "Avoid SQL Injection errors" cũng chỉ nêu nửa còn lại và bỏ qua phần hiệu năng khi chạy lặp. "Automatically commit transactions" sai hẳn vì việc chốt giao dịch do đối tượng kết nối quyết định qua cờ tự commit cùng hai lệnh commit và rollback; loại câu lệnh dùng để chạy SQL không can thiệp vào đó.

Đáp án đúng: "To handle exceptions thrown by Java code in the JSP". Khi mã Java trong trang JSP ném một ngoại lệ không được bắt, ngoại lệ ấy thoát khỏi phương thức phục vụ và container tra khai báo trang lỗi để biết đưa người dùng tới đâu: khai theo loại ngoại lệ kèm vị trí trang xử lý, còn trang xử lý thường bật thuộc tính báo mình là trang lỗi để dùng được đối tượng ẩn exception mà in thông điệp hay ghi log. "To declare custom error pages for specific HTTP error codes" nói về nhánh khai theo mã trạng thái HTTP, tức lo các mã do container sinh ra như 404 hay 500; đó là một công dụng khác của cùng khai báo, không phải điều câu hỏi đang nhắm tới. "To define global error handling for the entire web application" chỉ nói về phạm vi khai báo chứ không nói việc gì được xử lý, hơn nữa từng trang JSP vẫn có thể tự trỏ trang lỗi riêng bằng thuộc tính trong chỉ thị page. "To include additional resources in the JSP page" sai hẳn vì việc nhúng thêm tài nguyên vào trang thuộc chỉ thị include hoặc thẻ hành động include.

Đáp án đúng: "request". Đối tượng ẩn này có kiểu HttpServletRequest, do container tạo riêng cho từng yêu cầu rồi truyền vào phương thức phục vụ của servlet sinh ra từ trang; qua nó ta đọc tham số biểu mẫu, header, phương thức HTTP, địa chỉ được yêu cầu, cookie gửi lên và địa chỉ máy khách, tức toàn bộ thông tin về lần gọi hiện tại. "response" là phía ngược lại, dùng để tạo nội dung trả về, đặt mã trạng thái, header và chuyển hướng. "session" giữ dữ liệu bền hơn một yêu cầu cho cùng một người dùng, nên nó nói về trạng thái tích luỹ chứ không mô tả chi tiết của yêu cầu đang xử lý. "application" là đối tượng ẩn kiểu ServletContext, phạm vi toàn ứng dụng và dùng chung cho mọi người truy cập, càng không gắn với một yêu cầu cụ thể nào.

Đá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.

Đáp án đúng: "Servlet class". Ở pha dịch, container đọc trang JSP rồi sinh ra mã nguồn Java của một lớp kế thừa lớp cơ sở của JSP, lớp cơ sở đó lại hiện thực giao diện Servlet; mọi đoạn HTML tĩnh biến thành lệnh ghi ra luồng xuất và mọi scriptlet hay biểu thức nằm trong thân phương thức phục vụ. Lớp ấy được biên dịch rồi nạp, từ đó trang có đúng vòng đời của một servlet và được container gọi qua service. "JavaBean" là lớp dữ liệu thuần với các phương thức đọc ghi thuộc tính; JSP dùng bean để lấy dữ liệu chứ không biến thành bean. "Java Class" đúng ở mức thô vì kết quả cuối cũng là một lớp Java, nhưng nó bỏ mất chi tiết quyết định mà câu hỏi nhắm tới: lớp sinh ra thuộc loại servlet, có khởi tạo, phục vụ theo yêu cầu rồi bị huỷ. "XML Document" sai vì tuy JSP có thể viết theo cú pháp XML, kết quả của pha dịch là mã Java chứ không phải một tài liệu XML.

Đáp án đúng: "ServletA". Địa chỉ người dùng gõ chỉ tới đúng gốc ứng dụng mywebapp, nên phần đường dẫn bên trong ứng dụng là rỗng và được container quy về gốc. Khi so khớp, container thử lần lượt theo thứ tự: khớp chính xác, rồi khớp theo tiền tố, rồi khớp theo đuôi mở rộng, cuối cùng mới tới servlet mặc định được khai bằng một dấu gạch chéo đơn; ở đây không khai báo nào khớp chính xác nên servlet mặc định nhận yêu cầu. "ServletB" chỉ chạy khi đường dẫn đúng bằng chuỗi bservlet.html, trong khi yêu cầu này không hề có phần đó. "ServletC" chỉ chạy khi đường dẫn kết thúc bằng đuôi servletC, nhưng đường dẫn ở đây rỗng nên không có đuôi nào. "ServletD" chỉ nhận những đường dẫn bắt đầu bằng đoạn dservlet, cũng không khớp với một đường dẫn rỗng.