Code FAQ

If your question is not answered here, please see the Support FAQ, the AppWeb tech support FAQ, the AppWeb Product FAQ, or the licensing FAQ. You may submit your question to the online community support Forum.

Questions

Where can I get a source RPM?

How can I bypass the output buffering (largeFiles)?

If I rebuild the source, can I disable features at compile time?

Answers

Where can I get a source RPM?

The standard RPM Linux download include the source RPM.

How can I bypass the output buffering (largeFiles)?

First, a bit of background about DataStreams. DataStreams are a mechanism to allow AppWeb handlers to specify how their output data should be buffered and then returned back to the browser by the core HTTP server.

There are really three classes of data streams:

1 - A buffer for holding dynamically generated data.
2 - A stream that points to a file on disk
3 - An unbuffered data stream

For example: espHandler.cpp uses the 1st class and has the following code:

dynBuf = rq->getDynBuf();
rq->insertDataStream(dynBuf);

This hooks the dynamic buffer up to the output data stream. You need to fill the dynBuf with your data by using rq->write() or rq->writeFmt() for formatted output. NOTE: when you return from the handlers run() method you should only call rq->flushOutput only if you have buffered all your dynamic data. Otherwise, continue writing and call flushOutput whenever you are finished.

The copyHandler.cpp uses the 2nd class. It simply points to the file on disk and returns. The HTTP server will copy the file back to the browser piece by piece as the underlying socket generates writable events. AppWeb does not consume a thread for this as this can lead to thread starvation if every request blocks and consumes a thread.

The last class, unbuffered is used by handlers that wish to return very large amounts of dynamic data. Using the dynBuf would consume too much memory and so the app can write directly back and bypass the buffering mechanism.

Remember: Don't use rq->writeFmt if you have a large string. It must allocate a buffer to hold the formatted string. Use rq->write(), this will not allocate a buffer and will progressively flush the output. You can then call rq->flushOutput(1, 0) to flush the remaining portion. The first parameter to flushOutput() is a bool for do the flush in the background. Zero will do a foreground flush. The second parameter will close the request if TRUE. It must be zero for all but the last call.

The Dynamic buffering mechanism has a limit after which it will automatically flush. The limit is defined by the LimitResponseBody appWeb.conf directive. It defaults to 64K.

If I rebuild the source, can I disable features at compile time?

Yes. When AppWeb is built from source, a single bld.h header controls exactly what features and modules are built into the server. For example, if you don't require HTTP Keep-Alive support and you wish to minimize memory footprint, you can modify the MPR_FEATURE_HTTP_KEEP_ALIVE definition to be 0.

In version 1.1, the bld.h header has been enhanced and is now called mpr/mprConfig.h. Equivalent files for inclusion by make files and shell scripts are called config.sh and config.make respectively. Also, the FEATURE prefix is now BLD_.

If you have any further questions, please ask a question at the Forum.