Package dev.relism.flash.models
Class Http1HeaderMap
java.lang.Object
dev.relism.flash.models.Http1HeaderMap
- All Implemented Interfaces:
HeaderView
HeaderView backed directly by RequestParser's byte buffer — lazy, zero-copy:
strings are allocated only when first(java.lang.String)/all(java.lang.String)/view(java.lang.String) is called, the raw
bytes are never copied at parse time.
Package placement
Despite theHttp1 prefix, this class lives in dev.relism.flash.models, not
dev.relism.flash.http1, deliberately: RequestParser (which owns and resets one
instance per connection) lives in the root dev.relism.flash package, and http1
already depends on root (via Http1Connection's use of RequestParser) — placing
this class in http1 would require root to import back from http1, the exact
reader does not "fix" the location back to what the plan's Files list originally suggested.
Lifetime contract — read carefully
OneHttp1HeaderMap instance lives on the connection (not per-request). On every
keep-alive request reset(byte[], int, int) is called to slide the window over the new header
section of the same reused buffer. This has two critical implications:
- Do not retain the
Http1HeaderMapbeyond the handler. After the handler returns, the next request reuses and overwrites the buffer. AnyStringvalues retrieved viafirst(java.lang.String)/all(java.lang.String)are safe (they are independent heap copies); theHttp1HeaderMapobject itself is not. view(java.lang.String)returns a zero-copyByteViewslice into the live buffer, drawn from a smallSlicePool(seeview(java.lang.String)'s own Javadoc for the exact reuse window). Storing this view and reading it after the handler returns (e.g. in an async callback, aCompletableFuturecontinuation, or a virtual-thread handoff) is a data race — the bytes may have been overwritten by the next request. Copy to aStringorbyte[]before leaving the synchronous handler scope.
reset(byte[], int, int) scans the header section exactly once and records, per header, its name/value
byte offsets and a case-insensitive 32-bit hash of the name — into int[] arrays grown
(never shrunk) to this connection's high-water mark. Every lookup method
(first(java.lang.String), all(java.lang.String), view(java.lang.String), valueEqualsIgnoreCase(java.lang.String, java.lang.String)) then walks that
small index instead of rescanning raw bytes: a hash compare (cheap) before ever falling back to
a full case-insensitive name comparison.-
Nested Class Summary
Nested classes/interfaces inherited from interface dev.relism.flash.models.HeaderView
HeaderView.HeaderConsumer -
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionvoidaddParsed(int nameOffset, int nameLength, int valueOffset, int valueLength) Adds one already-validated header to the current zero-copy index.all()Returns all header values in declaration order.Returns all values of headernamein declaration order, or an empty list.voidbeginParsed(byte[] buffer, int sectionStart, int sectionEnd) Starts an index populated by the request parser while it validates the same header lines.booleanWhether any header namednameis present.intcount()Total number of header lines (not distinct names — a repeated header counts once per line).Returns the first value of headername(case-insensitive), ornull.voidforEach(HeaderView.HeaderConsumer consumer) Visits every header in declaration order without allocating a per-header object — see each implementation's Javadoc for exactly which instances are reused and their validity window.voidreset(byte[] buffer, int sectionStart, int sectionEnd) booleanvalueEqualsIgnoreCase(String name, String value) Case-insensitive comparison of the first value ofnameagainstvalue.dev.relism.fpr.core.ByteViewReturns a zero-copyByteViewover the first value ofname, ornull.
-
Constructor Details
-
Http1HeaderMap
public Http1HeaderMap()
-
-
Method Details
-
reset
public void reset(byte[] buffer, int sectionStart, int sectionEnd) -
beginParsed
public void beginParsed(byte[] buffer, int sectionStart, int sectionEnd) Starts an index populated by the request parser while it validates the same header lines. This avoids rescanning a validated section solely to recover offsets already known there. -
addParsed
public void addParsed(int nameOffset, int nameLength, int valueOffset, int valueLength) Adds one already-validated header to the current zero-copy index. -
forEach
Description copied from interface:HeaderViewVisits every header in declaration order without allocating a per-header object — see each implementation's Javadoc for exactly which instances are reused and their validity window.- Specified by:
forEachin interfaceHeaderView
-
first
Description copied from interface:HeaderViewReturns the first value of headername(case-insensitive), ornull.- Specified by:
firstin interfaceHeaderView
-
all
Description copied from interface:HeaderViewReturns all values of headernamein declaration order, or an empty list.- Specified by:
allin interfaceHeaderView
-
all
Description copied from interface:HeaderViewReturns all header values in declaration order.- Specified by:
allin interfaceHeaderView
-
valueEqualsIgnoreCase
Description copied from interface:HeaderViewCase-insensitive comparison of the first value ofnameagainstvalue.- Specified by:
valueEqualsIgnoreCasein interfaceHeaderView
-
contains
Description copied from interface:HeaderViewWhether any header namednameis present.- Specified by:
containsin interfaceHeaderView
-
count
public int count()Description copied from interface:HeaderViewTotal number of header lines (not distinct names — a repeated header counts once per line).- Specified by:
countin interfaceHeaderView
-
view
Returns a zero-copyByteViewover the first value ofname, ornull. The returned view is drawn from a small internalSlicePoolrather than allocated fresh. It stays valid until either the request ends, orview(java.lang.String)is called 4 more times on this sameHttp1HeaderMap— whichever comes first — at which point the ring wraps around and silently repositions the same instance over different bytes. A handler that needs more than 4 views alive at once should copy the earlier ones toString/byte[]before requesting more.- Specified by:
viewin interfaceHeaderView
-