What I sent you was captured from a security camera, it is what they have done for years. However, most my clients are not browsers! They are applications or plugins as I use mongose embedded, just like the cgi I am talking to here
Each section has a content length and the browser refreshes each time it gets a new myboundary section iirc it is constantly replacing the jpeg image in the same memory over and over again. Very similar to chunked encoding except this is allowed to have differnt types per boundary and to mix metadata with binary data. It is multiple instances instead of pieces of a whole that chunked encodeing was once written for. I have seen (I see every day) both styes of "streaming" data multipart mime for video framews, content length per --myboundary and chunked when the data is slow and less frequent like http alarms. Not sure why they prefer one or the other excpet maybe the browser knows already how to display the jpeg stream natively. ( I agree this is practiacally stone knifes and buckskin rugs, but it is still out there) On Fri, Aug 29, 2014 at 5:04 PM, Sergey Lyubka <[email protected]> wrote: > Hi Jeff, > I do not know whether that will be handled well by all browsers. > The standard says that if Content-Length is not set, then client should > expect the end of the data when TCP connection closes. > > The reply specifies HTTP/1.0 and Connection: close, so that should be > fine, but AFAIK there some browsers that ignore that: as soon as they send > HTTP/1.1 request, they won't close the connection. > > From the browser side, it will look like browser is waiting for data, > spinner would be spinning, and nothing will be rendered. > > To be bullet proof, I would either set Content-Length for the whole reply, > or use chunked encoding. > > > > > > On Fri, Aug 29, 2014 at 9:37 PM, jeff shanab <[email protected]> wrote: > >> is there anything special needed for something like... >> >> HTTP/1.0 200 OK >> Status: 200 >> Connection: close >> Content-type: multipart/x-mixed-replace;boundary =--myboundary >> >> --myboundary >> Content-type: image/jpeg >> Content-length: 203622 >> >> {binary data} >> >> --myboundary >> Content-type: image/jpeg >> Content-length: 203218 >> >> {binary data} >> >> and so on in which each frame, with the --myboundary and the headers is >> sent at each event loop iteration if the frame is ready. >> >> The thread I had before just looped calling my getframe() which blocked >> until the frame is ready. >> >> >> >> >> >> >> >> On Fri, Aug 29, 2014 at 3:55 PM, Sergey Lyubka <[email protected]> wrote: >> >>> Basically, >>> >>> if mg_write() is used, then HTTP headers must include content-length: >>> >>> case MG_REQUEST: >>> mg_write(conn, "HTTP/1.0 200 OK\r\n" >>> "Content-Length: %d\r\n\r\n", my_len); >>> mg_write(conn, .......); // "frames". Total data len must be my_len >>> mg_write(conn, .......); >>> return MG_TRUE; >>> >>> >>> >>> >>> >>> On Fri, Aug 29, 2014 at 7:56 PM, gregory kosinovsky < >>> [email protected]> wrote: >>> >>>> Is mg_more used for processing multiple frames in the same request? Do >>>> you have an example for doing that? >>>> >>>> Thank you, >>>> >>>> Greg >>>> >>>> >>>> On Thursday, August 28, 2014 4:44:29 PM UTC-7, gregory kosinovsky wrote: >>>>> >>>>> The return value on my mg_write(mg_connection*, void *, int) is about >>>>> 2 times what's expected -- my last parameter was set to 117072, but >>>>> mg_write returned 234300 (not exactly 2x, but very very close). >>>>> >>>>> What could be causing this? >>>>> >>>>> Thank you, >>>>> >>>>> Greg >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "mongoose-users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/mongoose-users. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "mongoose-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/mongoose-users. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "mongoose-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/mongoose-users. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "mongoose-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/mongoose-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "mongoose-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/mongoose-users. For more options, visit https://groups.google.com/d/optout.
