Merge branch 'develop' into copilot/convert-boost-to-std-string-view

Co-authored-by: mvadari <8029314+mvadari@users.noreply.github.com>

.claude/CLAUDE.md

@@ -1,54 +0,0 @@
-# Workflow Orchestration
-
-## 1. Plan Mode Default
-- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
-- If something goes sideways, STOP and re-plan immediately - don't keep pushing
-- Use plan mode for verification steps, not just building
-- Write detailed specs upfront to reduce ambiguity
-
-## 2. Subagent Strategy
-- Use subagents liberally to keep main context window clean
-- Offload research, exploration, and parallel analysis to subagents
-- For complex problems, throw compute at it via parallelizing
-- One task per subagent for focused execution
-
-## 3. Self-Improvement Loop
-- After ANY correction from the user: update `tasks/lessons.md` with the pattern
-- Write rules for yourself that prevent the same mistake
-- Ruthlessly iterate on these rules until mistake drops
-- Review lessons at session start for relevant project
-
-## 4. Verification Before Done
-- Never mark a task complete without proving it works
-- Diff behavior between main and your changes when relevant
-- Ask yourself: "Would a staff engineer approve this?"
-- Run tests, check logs, demonstrate correctness
-
-## 5. Demand Elegance (Balanced)
-- For non-trivial changes: pause and ask "is there a more elegant way?"
-- If a fix feels hacky: "Know now, do later, implement the elegant solution"
-- Skip this for simple, obvious fixes - don't over-engineer
-- Challenge your own first solution
-
-## 6. Autonomous Bug Fixing
-- When given a bug report: just fix it. Don't ask for hand-holding
-- Point at logs, errors, failing tests - then resolve them
-- Zero context switching required from the user
-- Go fix failing CI tests without being told how
-
-# Task Management
-
-1. **Plan First**: Write plan to `tasks/todo.md` with checkable items
-2. **Verify Plans**: Check in before starting implementation
-3. **Track Progress**: Mark items complete as you go
-4. **Explain Changes**: High-level summary at each step
-5. **Document Results**: Add review section to `tasks/todo.md`
-6. **Capture Lessons**: Update `tasks/lessons.md` after corrections
-
-# Core Principles
-
-**Simplicity First**: Make every change as simple as possible. Impact minimal code.
-
-**No Boilerplate**: Skip documentation. No README/docs bloat. Test only if requested.
-
-**Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs.

.claude/skills/amendment.md

@@ -1,530 +0,0 @@
-# XRPL Amendment Creation Skill
-
-This skill guides you through creating XRPL amendments, whether for brand new features or fixes/extensions to existing functionality.
-
-## Amendment Types
-
-There are two main types of amendments:
-
-1. **New Feature Amendment** (`feature{Name}`) - Entirely new functionality
-2. **Fix/Extension Amendment** (`fix{Name}`) - Modifications to existing functionality
-
-## Step 1: Determine Amendment Type
-
-Ask the user:
-- Is this a **brand new feature** (new transaction type, ledger entry, or capability)?
-- Or is this a **fix or extension** to existing functionality?
-
----
-
-## For NEW FEATURE Amendments
-
-### Checklist:
-
-#### 1. Feature Definition in features.macro
-**ONLY FILE TO EDIT:** `include/xrpl/protocol/detail/features.macro`
-
-- [ ] Add to TOP of features.macro (reverse chronological order):
-```
-XRPL_FEATURE(YourFeatureName, Supported::no, VoteBehavior::DefaultNo)
-```
-- [ ] This creates the variable `featureYourFeatureName` automatically
-- [ ] Follow naming convention: Use the feature name WITHOUT the "feature" prefix
-- [ ] Examples: `Batch` → `featureBatch`, `LendingProtocol` → `featureLendingProtocol`
-
-#### 2. Support Status
-- [ ] Start with `Supported::no` during development
-- [ ] Change to `Supported::yes` when ready for network voting
-- [ ] Use `VoteBehavior::DefaultNo` (validators must explicitly vote for it)
-
-#### 3. Code Implementation
-- [ ] Implement new functionality (transaction type, ledger entry, etc.)
-- [ ] Add feature gate check in preflight:
-```cpp
-if (!env.current()->rules().enabled(feature{Name}))
-{
-    return temDISABLED;
-}
-```
-
-#### 4. Disable Route Handling
-- [ ] Ensure transaction returns `temDISABLED` when amendment is disabled
-- [ ] Implement early rejection in preflight/preclaim phase
-- [ ] Add appropriate error messages
-
-#### 5. Test Implementation
-Create comprehensive test suite with this structure:
-
-```cpp
-class {FeatureName}_test : public beast::unit_test::suite
-{
-public:
-    void testEnable(FeatureBitset features)
-    {
-        testcase("enabled");
-
-        // Test with feature DISABLED
-        {
-            auto const amendNoFeature = features - feature{Name};
-            Env env{*this, amendNoFeature};
-
-            env(transaction, ter(temDISABLED));
-        }
-
-        // Test with feature ENABLED
-        {
-            Env env{*this, features};
-
-            env(transaction, ter(tesSUCCESS));
-            // Validate new functionality works
-        }
-    }
-
-    void testPreflight(FeatureBitset features)
-    {
-        testcase("preflight");
-        // Test malformed transaction validation
-    }
-
-    void testPreclaim(FeatureBitset features)
-    {
-        testcase("preclaim");
-        // Test signature and claim phase validation
-    }
-
-    void testWithFeats(FeatureBitset features)
-    {
-        testEnable(features);
-        testPreflight(features);
-        testPreclaim(features);
-        // Add feature-specific tests
-    }
-
-    void run() override
-    {
-        using namespace test::jtx;
-        auto const all = supported_amendments();
-        testWithFeats(all);
-    }
-};
-```
-
-#### 6. Test Coverage Requirements
-- [ ] Test amendment DISABLED state (returns `temDISABLED`)
-- [ ] Test amendment ENABLED state (returns `tesSUCCESS`)
-- [ ] Test malformed transactions
-- [ ] Test signature validation
-- [ ] Test edge cases specific to feature
-- [ ] Test amendment transition behavior
-
-#### 7. Documentation
-- [ ] Create specification document (XLS_{NAME}.md)
-- [ ] Document new transaction types, ledger entries, or capabilities
-- [ ] Create test plan document
-- [ ] Document expected behavior when enabled/disabled
-
----
-
-## For FIX/EXTENSION Amendments
-
-### Checklist:
-
-#### 1. Fix Definition in features.macro
-**ONLY FILE TO EDIT:** `include/xrpl/protocol/detail/features.macro`
-
-- [ ] Add to TOP of features.macro (reverse chronological order):
-```
-XRPL_FIX(YourFixName, Supported::no, VoteBehavior::DefaultNo)
-```
-- [ ] This creates the variable `fixYourFixName` automatically
-- [ ] Follow naming convention: Use the fix name WITHOUT the "fix" prefix (it's added automatically)
-- [ ] Examples: `TokenEscrowV1` → `fixTokenEscrowV1`, `DirectoryLimit` → `fixDirectoryLimit`
-- [ ] Start with `Supported::no` during development, change to `Supported::yes` when ready
-
-#### 2. Backward Compatibility Implementation
-**Critical**: Use enable() with if/else to preserve existing functionality
-
-```cpp
-// Check if fix is enabled
-bool const fix{Name} = env.current()->rules().enabled(fix{Name});
-
-// Conditional logic based on amendment state
-if (fix{Name})
-{
-    // NEW behavior with fix applied
-    // This is the corrected/improved logic
-}
-else
-{
-    // OLD behavior (legacy path)
-    // Preserve original functionality for backward compatibility
-}
-```
-
-**Alternative pattern with ternary operator:**
-```cpp
-auto& viewToUse = sb.rules().enabled(fix{Name}) ? sb : legacyView;
-```
-
-#### 3. Multiple Fix Versions Pattern
-For iterative fixes, use version checking:
-
-```cpp
-bool const fixV1 = rv.rules().enabled(fixXahauV1);
-bool const fixV2 = rv.rules().enabled(fixXahauV2);
-
-switch (transactionType)
-{
-    case TYPE_1:
-        if (fixV1) {
-            // Behavior with V1 fix
-        } else {
-            // Legacy behavior
-        }
-        break;
-
-    case TYPE_2:
-        if (fixV2) {
-            // Behavior with V2 fix
-        } else if (fixV1) {
-            // Behavior with only V1
-        } else {
-            // Legacy behavior
-        }
-        break;
-}
-```
-
-#### 4. Test Both Paths
-Always test BOTH enabled and disabled states:
-
-```cpp
-void testFix(FeatureBitset features)
-{
-    testcase("fix behavior");
-
-    for (bool withFix : {false, true})
-    {
-        auto const amend = withFix ? features : features - fix{Name};
-        Env env{*this, amend};
-
-        // Setup test scenario
-        env.fund(XRP(1000), alice);
-        env.close();
-
-        if (!withFix)
-        {
-            // Test OLD behavior (before fix)
-            env(operation, ter(expectedErrorWithoutFix));
-            // Verify old behavior is preserved
-        }
-        else
-        {
-            // Test NEW behavior (after fix)
-            env(operation, ter(expectedErrorWithFix));
-            // Verify fix works correctly
-        }
-    }
-}
-```
-
-#### 5. Security Fix Pattern
-For security-critical fixes (like fixBatchInnerSigs):
-
-```cpp
-// Test vulnerability exists WITHOUT fix
-{
-    auto const amendNoFix = features - fix{Name};
-    Env env{*this, amendNoFix};
-
-    // Demonstrate vulnerability
-    // Expected: Validity::Valid (WRONG - vulnerable!)
-    BEAST_EXPECT(result == Validity::Valid);
-}
-
-// Test vulnerability is FIXED WITH amendment
-{
-    Env env{*this, features};
-
-    // Demonstrate fix
-    // Expected: Validity::SigBad (CORRECT - protected!)
-    BEAST_EXPECT(result == Validity::SigBad);
-}
-```
-
-#### 6. Test Coverage Requirements
-- [ ] Test fix DISABLED (legacy behavior preserved)
-- [ ] Test fix ENABLED (new behavior applied)
-- [ ] Test amendment transition
-- [ ] For security fixes: demonstrate vulnerability without fix
-- [ ] For security fixes: demonstrate protection with fix
-- [ ] Test edge cases that triggered the fix
-- [ ] Test combinations with other amendments
-
-#### 7. Documentation
-- [ ] Document what was broken/suboptimal
-- [ ] Document the fix applied
-- [ ] Document backward compatibility behavior
-- [ ] Create test summary showing both paths
-
----
-
-## Best Practices for All Amendments
-
-### 1. Naming Conventions
-- New features: `feature{DescriptiveName}` (e.g., `featureBatch`, `featureHooks`)
-- Fixes: `fix{IssueDescription}` (e.g., `fixBatchInnerSigs`, `fixNSDelete`)
-- Use CamelCase without underscores
-
-### 2. Feature Flag Checking
-```cpp
-// At the point where behavior diverges:
-bool const amendmentEnabled = env.current()->rules().enabled(feature{Name});
-
-// Or in view/rules context:
-if (!rv.rules().enabled(feature{Name}))
-    return {};  // or legacy behavior
-```
-
-### 3. Error Codes
-- New features when disabled: `temDISABLED`
-- Fixes may return different validation errors based on state
-- Document all error code changes
-
-### 4. Test Structure Template
-```cpp
-class Amendment_test : public beast::unit_test::suite
-{
-public:
-    // Core tests
-    void testEnable(FeatureBitset features);      // Enable/disable states
-    void testPreflight(FeatureBitset features);   // Validation
-    void testPreclaim(FeatureBitset features);    // Claim phase
-
-    // Feature-specific tests
-    void test{SpecificScenario1}(FeatureBitset features);
-    void test{SpecificScenario2}(FeatureBitset features);
-
-    // Master orchestrator
-    void testWithFeats(FeatureBitset features)
-    {
-        testEnable(features);
-        testPreflight(features);
-        testPreclaim(features);
-        test{SpecificScenario1}(features);
-        test{SpecificScenario2}(features);
-    }
-
-    void run() override
-    {
-        using namespace test::jtx;
-        auto const all = supported_amendments();
-        testWithFeats(all);
-    }
-};
-
-BEAST_DEFINE_TESTSUITE(Amendment, app, ripple);
-```
-
-### 5. Documentation Files
-Create these files:
-- **Specification**: `XLS_{FEATURE_NAME}.md` - Technical specification
-- **Test Plan**: `{FEATURE}_COMPREHENSIVE_TEST_PLAN.md` - Test strategy
-- **Test Summary**: `{FEATURE}_TEST_IMPLEMENTATION_SUMMARY.md` - Test results
-- **Review Findings**: `{FEATURE}_REVIEW_FINDINGS.md` (if applicable)
-
-### 6. Amendment Transition Testing
-Test the moment an amendment activates:
-
-```cpp
-void testAmendmentTransition(FeatureBitset features)
-{
-    testcase("amendment transition");
-
-    // Start with amendment disabled
-    auto const amendNoFeature = features - feature{Name};
-    Env env{*this, amendNoFeature};
-
-    // Perform operations in disabled state
-    env(operation1, ter(temDISABLED));
-
-    // Enable amendment mid-test (if testing mechanism supports it)
-    // Verify state transitions correctly
-
-    // Perform operations in enabled state
-    env(operation2, ter(tesSUCCESS));
-}
-```
-
-### 7. Cache Behavior
-If amendment affects caching (like fixBatchInnerSigs):
-- [ ] Test cache behavior without fix
-- [ ] Test cache behavior with fix
-- [ ] Document cache invalidation requirements
-
-### 8. Multi-Amendment Combinations
-Test interactions with other amendments:
-
-```cpp
-void testMultipleAmendments(FeatureBitset features)
-{
-    // Test all combinations
-    for (bool withFeature1 : {false, true})
-    for (bool withFeature2 : {false, true})
-    {
-        auto amend = features;
-        if (!withFeature1) amend -= feature1;
-        if (!withFeature2) amend -= feature2;
-
-        Env env{*this, amend};
-        // Test interaction behavior
-    }
-}
-```
-
-### 9. Performance Considerations
-- [ ] Minimize runtime checks (cache `rules().enabled()` result if used multiple times)
-- [ ] Avoid nested feature checks where possible
-- [ ] Document performance impact
-
-### 10. Code Review Checklist
-- [ ] Both enabled/disabled paths are tested
-- [ ] Backward compatibility is preserved (for fixes)
-- [ ] Error codes are appropriate
-- [ ] Documentation is complete
-- [ ] Security implications are considered
-- [ ] Cache behavior is correct
-- [ ] Edge cases are covered
-
----
-
-## Common Patterns Reference
-
-### Pattern: New Transaction Type
-```cpp
-// In transactor code:
-TER doApply() override
-{
-    if (!ctx_.view().rules().enabled(feature{Name}))
-        return temDISABLED;
-
-    // New transaction logic here
-    return tesSUCCESS;
-}
-```
-
-### Pattern: New Ledger Entry Type
-```cpp
-// In ledger entry creation:
-if (!view.rules().enabled(feature{Name}))
-    return temDISABLED;
-
-auto const sle = std::make_shared<SLE>(ltNEW_TYPE, keylet);
-view.insert(sle);
-```
-
-### Pattern: Behavioral Fix
-```cpp
-// At decision point:
-bool const useFix = view.rules().enabled(fix{Name});
-
-if (useFix)
-{
-    // Corrected behavior
-    return performCorrectValidation();
-}
-else
-{
-    // Legacy behavior (preserved for compatibility)
-    return performLegacyValidation();
-}
-```
-
-### Pattern: View Selection
-```cpp
-// Select which view to use based on amendment:
-auto& applyView = sb.rules().enabled(feature{Name}) ? newView : legacyView;
-```
-
----
-
-## Example Workflows
-
-### Workflow 1: Creating a New Feature Amendment
-
-1. User requests: "Add a new ClaimReward transaction type"
-2. Skill asks: "What should the amendment be called? (e.g., BalanceRewards - without 'feature' prefix)"
-3. Add to features.macro:
-```
-XRPL_FEATURE(BalanceRewards, Supported::no, VoteBehavior::DefaultNo)
-```
-4. Implement transaction with `temDISABLED` gate using `featureBalanceRewards`
-5. Create test suite with testEnable, testPreflight, testPreclaim
-6. Run tests with amendment enabled and disabled
-7. When ready, update to `Supported::yes` in features.macro
-8. Create specification document
-9. Review checklist
-
-### Workflow 2: Creating a Fix Amendment
-
-1. User requests: "Fix the signature validation bug in batch transactions"
-2. Skill asks: "What should the fix be called? (e.g., BatchInnerSigs - without 'fix' prefix)"
-3. Add to features.macro:
-```
-XRPL_FIX(BatchInnerSigs, Supported::no, VoteBehavior::DefaultNo)
-```
-4. Implement fix with if/else using `fixBatchInnerSigs` to preserve old behavior
-5. Create test demonstrating vulnerability without fix
-6. Create test showing fix works when enabled
-7. When ready, update to `Supported::yes` in features.macro
-8. Document both code paths
-9. Review checklist
-
----
-
-## Quick Reference: File Locations
-
-- **Amendment definitions (ONLY place to add)**: `include/xrpl/protocol/detail/features.macro`
-- **Feature.h (auto-generated, DO NOT EDIT)**: `include/xrpl/protocol/Feature.h`
-- **Feature.cpp (auto-generated, DO NOT EDIT)**: `src/libxrpl/protocol/Feature.cpp`
-- **Test files**: `src/test/app/` or `src/test/protocol/`
-- **Specifications**: Project root (e.g., `XLS_SMART_CONTRACTS.md`)
-- **Test plans**: Project root (e.g., `BATCH_COMPREHENSIVE_TEST_PLAN.md`)
-
-## How the Macro System Works
-
-The amendment system uses C preprocessor macros:
-
-1. **features.macro** - Single source of truth (ONLY file you edit):
-```
-XRPL_FEATURE(Batch, Supported::yes, VoteBehavior::DefaultNo)
-XRPL_FIX(TokenEscrowV1, Supported::yes, VoteBehavior::DefaultNo)
-```
-
-2. **Feature.h** - Auto-generated declarations from macro:
-```cpp
-extern uint256 const featureBatch;
-extern uint256 const fixTokenEscrowV1;
-```
-
-3. **Feature.cpp** - Auto-generated registrations from macro:
-```cpp
-uint256 const featureBatch = registerFeature("Batch", ...);
-uint256 const fixTokenEscrowV1 = registerFeature("fixTokenEscrowV1", ...);
-```
-
-**DO NOT** modify Feature.h or Feature.cpp directly - they process features.macro automatically.
-
----
-
-## When to Use This Skill
-
-Invoke this skill when:
-- Creating a new XRPL amendment
-- Adding a new transaction type or ledger entry
-- Fixing existing XRPL functionality
-- Need guidance on amendment best practices
-- Setting up amendment tests
-- Reviewing amendment implementation
-
-The skill will guide you through the appropriate workflow based on amendment type.

.gitignore

@@ -69,3 +69,5 @@ DerivedData
 
 # AI tools.
 /.augment
+/.claude
+/CLAUDE.md

include/xrpl/beast/rfc2616.h

@@ -10,6 +10,7 @@
 #include <cctype>
 #include <iterator>
 #include <string>
+#include <string_view>
 #include <vector>
 
 namespace beast {
@@ -178,7 +179,7 @@ split_commas(FwdIt first, FwdIt last)
 
 template <class Result = std::vector<std::string>>
 Result
-split_commas(boost::beast::string_view const& s)
+split_commas(std::string_view const& s)
 {
     return split_commas(s.begin(), s.end());
 }

include/xrpl/json/Output.h

@@ -1,20 +1,19 @@
 #pragma once
 
-#include <boost/beast/core/string.hpp>
-
 #include <functional>
 #include <string>
+#include <string_view>
 
 namespace Json {
 
 class Value;
 
-using Output = std::function<void(boost::beast::string_view const&)>;
+using Output = std::function<void(std::string_view const&)>;
 
 inline Output
 stringOutput(std::string& s)
 {
-    return [&](boost::beast::string_view const& b) { s.append(b.data(), b.size()); };
+    return [&](std::string_view const& b) { s.append(b.data(), b.size()); };
 }
 
 /** Writes a minimal representation of a Json value to an Output in O(n) time.

include/xrpl/server/detail/BaseWSPeer.h

@@ -17,6 +17,7 @@
 
 #include <functional>
 #include <list>
+#include <string_view>
 
 namespace xrpl {
 
@@ -48,7 +49,7 @@ private:
     bool ping_active_ = false;
     boost::beast::websocket::ping_data payload_;
     error_code ec_;
-    std::function<void(boost::beast::websocket::frame_type, boost::beast::string_view)> control_callback_;
+    std::function<void(boost::beast::websocket::frame_type, std::string_view)> control_callback_;
 
 public:
     template <class Body, class Headers>
@@ -136,7 +137,7 @@ protected:
     on_ping(error_code const& ec);
 
     void
-    on_ping_pong(boost::beast::websocket::frame_type kind, boost::beast::string_view payload);
+    on_ping_pong(boost::beast::websocket::frame_type kind, std::string_view payload);
 
     void
     on_timer(error_code ec);
@@ -389,11 +390,11 @@ BaseWSPeer<Handler, Impl>::on_ping(error_code const& ec)
 
 template <class Handler, class Impl>
 void
-BaseWSPeer<Handler, Impl>::on_ping_pong(boost::beast::websocket::frame_type kind, boost::beast::string_view payload)
+BaseWSPeer<Handler, Impl>::on_ping_pong(boost::beast::websocket::frame_type kind, std::string_view payload)
 {
     if (kind == boost::beast::websocket::frame_type::pong)
     {
-        boost::beast::string_view p(payload_.begin());
+        std::string_view p(payload_.begin(), payload_.size());
         if (payload == p)
         {
             close_on_timer_ = false;

src/libxrpl/json/Writer.cpp

@@ -8,6 +8,7 @@
 #include <set>
 #include <stack>
 #include <string>
+#include <string_view>
 #include <utility>
 #include <vector>
 
@@ -87,14 +88,14 @@ public:
     }
 
     void
-    output(boost::beast::string_view const& bytes)
+    output(std::string_view const& bytes)
     {
         markStarted();
         output_(bytes);
     }
 
     void
-    stringOutput(boost::beast::string_view const& bytes)
+    stringOutput(std::string_view const& bytes)
     {
         markStarted();
         std::size_t position = 0, writtenUntil = 0;

src/xrpld/overlay/detail/ProtocolVersion.cpp

@@ -58,7 +58,7 @@ to_string(ProtocolVersion const& p)
 }
 
 std::vector<ProtocolVersion>
-parseProtocolVersions(boost::beast::string_view const& value)
+parseProtocolVersions(std::string_view const& value)
 {
     static boost::regex re(
         "^"                        // start of line
@@ -127,7 +127,7 @@ negotiateProtocolVersion(std::vector<ProtocolVersion> const& versions)
 }
 
 std::optional<ProtocolVersion>
-negotiateProtocolVersion(boost::beast::string_view const& versions)
+negotiateProtocolVersion(std::string_view const& versions)
 {
     auto const them = parseProtocolVersions(versions);
 

src/xrpld/overlay/detail/ProtocolVersion.h

@@ -1,10 +1,9 @@
 #pragma once
 
-#include <boost/beast/core/string.hpp>
-
 #include <cstdint>
 #include <optional>
 #include <string>
+#include <string_view>
 #include <utility>
 #include <vector>
 
@@ -39,7 +38,7 @@ to_string(ProtocolVersion const& p);
           no duplicates and will be sorted in ascending protocol order.
 */
 std::vector<ProtocolVersion>
-parseProtocolVersions(boost::beast::string_view const& s);
+parseProtocolVersions(std::string_view const& s);
 
 /** Given a list of supported protocol versions, choose the one we prefer. */
 std::optional<ProtocolVersion>
@@ -47,7 +46,7 @@ negotiateProtocolVersion(std::vector<ProtocolVersion> const& versions);
 
 /** Given a list of supported protocol versions, choose the one we prefer. */
 std::optional<ProtocolVersion>
-negotiateProtocolVersion(boost::beast::string_view const& versions);
+negotiateProtocolVersion(std::string_view const& versions);
 
 /** The list of all the protocol versions we support. */
 std::string const&

src/xrpld/rpc/detail/ServerHandler.cpp

@@ -34,6 +34,7 @@
 #include <algorithm>
 #include <memory>
 #include <stdexcept>
+#include <string_view>
 
 namespace xrpl {
 
@@ -227,7 +228,7 @@ ServerHandler::onHandoff(
 static inline Json::Output
 makeOutput(Session& session)
 {
-    return [&](boost::beast::string_view const& b) { session.write(b.data(), b.size()); };
+    return [&](std::string_view const& b) { session.write(b.data(), b.size()); };
 }
 
 static std::map<std::string, std::string>
@@ -511,11 +512,14 @@ ServerHandler::processSession(std::shared_ptr<Session> const& session, std::shar
         makeOutput(*session),
         coro,
         forwardedFor(session->request()),
-        [&] {
+        [&]() -> std::string_view {
             auto const iter = session->request().find("X-User");
             if (iter != session->request().end())
-                return iter->value();
-            return boost::beast::string_view{};
+            {
+                auto const val = iter->value();
+                return std::string_view(val.data(), val.size());
+            }
+            return std::string_view{};
         }());
 
     if (beast::rfc2616::is_keep_alive(session->request()))