1Y0-340 · Question #104
Scenario: A Citrix Engineer receives the following error when accessing content from a virtual server: "Page cannot be displayed." However, the content is accessible when connecting directly to the…
The correct answer is B. Enable Drop extra data from server in the HTTP Profile. See the full explanation below for the reasoning.
Question
Scenario: A Citrix Engineer receives the following error when accessing content from a virtual server:
“Page cannot be displayed.” However, the content is accessible when connecting directly to the web server. The engineer captured the traffic using nstrace and found that the amount of data sent from the web server exceeds the content length defined in the HTTP header. Which action can the engineer take to resolve the issue?
Options
- ADisable Drop extra CRLF in the HTTP Profile.
- BEnable Drop extra data from server in the HTTP Profile.
- CIncrease the Content length in the Application Firewall Profile.
- DDisable Drop extra data from server in the HTTP Profile.
How the community answered
(60 responses)- A3% (2)
- B77% (46)
- C13% (8)
- D7% (4)
Community Discussion
7
Nina C.Feb 27, 2026The answer is B, enable Drop extra data from server in the HTTP Profile, because when the web server sends more data than the Content-Length header declares, the NetScaler gets confused about where the response ends, so enabling that setting tells it to simply discard the overflow and deliver only what the header promised. That mismatch is exactly what causes the "Page cannot be displayed" error through the virtual server even though the direct connection works fine.
Grace U.Mar 5, 2026The trace is telling you exactly what the ADC is choking on, which is a server sending more bytes than it promised in the Content-Length header, and the NetScaler virtual server is treating that mismatch as a broken or potentially malicious response. Does the phrase "extra data" in the HTTP Profile options help you see which setting is designed to handle precisely this kind of server-side sloppiness, and in which direction you would need to flip it to allow traffic through rather than block it?
Giovanna H.Mar 5, 2026Grace is right that "extra data" is the lever, though worth noting you should set it on the HTTP Profile bound to the service side (the backend service group), not the virtual server's client-side profile, since the mismatch originates from the server response, not the client request.
Giovanna H.Mar 16, 2026Disabling that setting lets the extra server data through, clearing the display error.
Grace U.Mar 18, 2026Giovanna, that reasoning actually describes a side effect rather than the fix, and the correct answer here is B because option B addresses the root cause at the protocol level rather than just allowing more data through the affected setting. Take a second look at how B handles the handshake step, and it should click.
Giselle K.Feb 24, 2026The Application Firewall Profile is where content length inspection lives, and when the WAF sees a response body that blows past the declared Content-Length, it drops the transaction and the client gets that "Page cannot be displayed" error. The nstrace output is the giveaway here, it shows the server sending more data than the header advertises, which is exactly the kind of anomaly the AppFW content length check is designed to flag and block. Bumping the Content Length value in the AppFW Profile gives that inspection threshold enough headroom to let the full response through without the appliance treating it as a violation. I sat with this one for a while and C is where my confidence lands, the HTTP Profile options in A, B, D are more about how the ADC parses and forwards HTTP chunks, not about the WAF blocking an oversized body.
Grace U.Feb 25, 2026Giselle, that reasoning makes intuitive sense, but the content length mismatch here is tripped by the HTTP Profile setting on the virtual server, not the AppFW, because the ADC enforces response body size consistency at the HTTP processing layer before WAF inspection even enters the picture, so raising the threshold in the HTTP Profile, option B, is what actually resolves the client-side error.