Skip to content

Conversation

@NattyNarwhal
Copy link
Contributor

@NattyNarwhal NattyNarwhal commented Jun 4, 2025

See #2848 for the justification, but it should simplify the case of viewing the HTML reports when GoAccess is being run on another system.

On mind for this:

  • The send code is somewhat unreliable; it will stop accepting new data for the buffers to send, truncating the output.
  • Doesn't handle static resources split out to other files yet (--external-assets) Does so now.
  • ~~It'd probably be more efficient to read the file once and then send it, since the report shouldn't change on disk until it's re-ran. It might help alleviate the issues with ~~ Doesn't seem to help this part - though it seems to truncate around ~32k, and small reports/the CSS are fine, larger reports, the JS are not.
  • It may be better to make find_output_type not allocate at all and make callers do that.

This does mean you have to cast and conflates caller frees vs. caller
doesn't free. Done to avoid an alloc.
If you're serving real-time reports in an ad-hoc manner, it can be
annoying to set up another web server to return the HTML. This makes it
so that the same web server used for WebSocket updates can also serve
the HTML.

Many problems likely; I have not yet audited this. It is somewhat buggy
too - ws_send_response likes to not return anything and thus truncates
the buffer. I'm trying to find a solution to this.

It also probably needs to handle the case when static resources are
served in many different files.
Should avoid constant fopen, but doesn't seem to improve the truncated
send buffer.
Expose get_asset_filename, load those too, and a little cleanup around
serving resources.
@allinurl
Copy link
Owner

allinurl commented Jun 6, 2025

Thanks for this PR! I'm seeing a net::ERR_CONTENT_LENGTH_MISMATCH response, and as you mentioned, it seems like ws_respond is only sending 108,600 bytes instead of the expected 734,919 bytes (file size).

Since the WS server is fundamentally built around the event loop, sending the remainder of the HTTP response will need to integrate with it properly. Given that the response is being queued in the send buffer, we'll need to adjust how ws_send_http_response is invoked and to use the event loop. I'll take a close look and follow up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants