The current HTTP receptor code works by passing to STREAM_READ: HTTP_REQUEST as the transcoding RESULT_SYMBOL. This doesn't really work because the current (false) assumption is that the HTTP request is in a single LINE (STREAM_READ currently works on a single line returned by _st_read) instead we need to build something where a transcoder can work on a stream over time (i.e. it doesn't break if things arrive partially). Thus, it could part the HTTP method and version from the first LINE with one semtrex, and the headers from the subsequent lines with a different semtrex, and all of this needs to be composed with nice reusable expressivity from the programmers point of view...
The current HTTP receptor code works by passing to STREAM_READ: HTTP_REQUEST as the transcoding RESULT_SYMBOL. This doesn't really work because the current (false) assumption is that the HTTP request is in a single LINE (STREAM_READ currently works on a single line returned by _st_read) instead we need to build something where a transcoder can work on a stream over time (i.e. it doesn't break if things arrive partially). Thus, it could part the HTTP method and version from the first LINE with one semtrex, and the headers from the subsequent lines with a different semtrex, and all of this needs to be composed with nice reusable expressivity from the programmers point of view...