Improve Tunnel Server RESPONSE dumps #1975
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
"Tunnel Server RESPONSE" debugs() in Http::Tunneler::handleResponse() incorrectly assumed that readBuf contained hdr_sz bytes, but in reality it contains no header bytes and usually is empty. To avoid such problems we must pair rawContent() with the SBuf's length().
Adjusted Http::Tunneler::handleResponse() in line with a similar HttpStateData::processReplyHeader().
rousskov
approved these changes
Dec 30, 2024
There was a problem hiding this comment.
Thank you for fixing this bug. I believe this PR explicit decision to duplicate old/known HttpStateData::processReplyHeader() problems (for now) is an acceptable step forward. I hope to find the time to fix those old problems (in dedicated PRs), and this PR facilitates those future fixes.
FWIW, here is a sample of Valgrind message that discovered the bug fixed by this PR:
Conditional jump or move depends on uninitialised value(s)
at 0x484ED28: strlen (vg_replace_strmem.c:494)
by 0x529FD30: __vfprintf_internal (vfprintf-internal.c:1517)
by 0x52896C9: fprintf (fprintf.c:32)
by 0xA0AAAC: DebugChannel::writeToStream(_IO_FILE&, DebugMessageHeader const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (debug.cc:615)
by 0xA0AB70: CacheLogChannel::write(DebugMessageHeader const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (debug.cc:640)
by 0xA0A38A: DebugChannel::log(DebugMessageHeader const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (debug.cc:550)
by 0xA09F80: DebugModule::log(DebugMessageHeader const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (debug.cc:449)
by 0xA0B226: Debug::LogMessage(Debug::Context const&) (debug.cc:818)
by 0xA0C752: Debug::Finish() (debug.cc:1392)
by 0x829226: Http::Tunneler::handleResponse(bool) (HttpTunneler.cc:317)
by 0x82863C: Http::Tunneler::handleReadyRead(CommIoCbParams const&) (HttpTunneler.cc:230)
by 0x82B922: CommCbMemFunT<Http::Tunneler, CommIoCbParams>::doDial() (CommCalls.h:190)
by 0x82BB14: JobDialer<Http::Tunneler>::dial(AsyncCall&) (AsyncJobCalls.h:176)
by 0x82B668: AsyncCallT<CommCbMemFunT<Http::Tunneler, CommIoCbParams> >::fire() (AsyncCall.h:148)
by 0x870970: AsyncCall::make() (AsyncCall.cc:44)
by 0x871F2F: AsyncCallQueue::fire() (AsyncCallQueue.cc:27)
by 0x5B2D80: EventLoop::dispatchCalls() (EventLoop.cc:144)
by 0x5B2C8C: EventLoop::runOnce() (EventLoop.cc:121)
by 0x5B2ADF: EventLoop::run() (EventLoop.cc:83)
by 0x70FDC4: SquidMain(int, char**) (main.cc:1727)
by 0x70EC4E: SquidMainSafe(int, char**) (main.cc:1351)
by 0x70EC08: main (main.cc:1339)
| HttpReply::Pointer rep = new HttpReply; | ||
| rep->sources |= Http::Message::srcHttp; | ||
| rep->sline.set(hp->messageProtocol(), hp->messageStatus()); | ||
| if (!rep->parseHeader(*hp) && rep->sline.status() == Http::scOkay) { | ||
| bailOnResponseError("malformed CONNECT response from peer", nullptr); | ||
| bailOnResponseError("malformed CONNECT response headers mime block from peer", nullptr); |
There was a problem hiding this comment.
This specific change makes this bailOnResponseError() reason distinct from !parsedOk reason. The adjusted wording is a bit awkward, but it now matches the wording used by HttpStateData::processReplyHeader(). Since this PR reuses relevant processReplyHeader() code (with all its problems), I think this is the right change; it and can be viewed as being in this PR scope.
This comment does not request any changes.
rousskov
added
M-cleared-for-merge
kinkie
approved these changes
Dec 30, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Level-2 "Tunnel Server RESPONSE:..." debugs() incorrectly assumed that
its readBuf parameter contained hdr_sz header bytes. In reality, by the
time code reached that debugs(), readBuf no longer had any header bytes
(and often had no bytes at all). Besides broken header dumps, this bug
could lead to problems that Valgrind reports as "Conditional jump or
move depends on uninitialised value" in DebugChannel::writeToStream().
This fix mimics HttpStateData::processReplyHeader() reporting code,
including its known problems. Future changes should address those
problems and reduce code duplication across at least ten functions
containing similar "decorated" level-2 message dumps.