Large(ish) strings failing to send over WiFi101 using WiFiServer
As per my notes the WINC1500 has a limit of 1500 bytes per transmission.  But some of this is always taken up by TCP overhead so the payload buffer must be smaller, that's why you see numbers like 1460.

From:
http://ww1.microchip.com/downloads/en/appnotes/atmel-42739-tcp-client-and-server-operation-using-atwinc1500_at14596_applicationnote.pdf


  2.2.2 TCP Packet Size 
  
  A packet is sized as per the lowest MTU (Maximum
  Transmission Unit) on the path, which is typically 1500 bytes (for
  Ethernet) of data including TCP (20 bytes) and IP headers (20 bytes).
  The packet size is defined in main.h as :


#define MAIN_WIFI_M2M_BUFFER_SIZE 1460 



  The application then defines a socket buffer of this size in main.c as: 


static uint8_t gau8SocketTestBuffer[MAIN_WIFI_M2M_BUFFER_SIZE];


This means that HTTP responses over ~1400 bytes need to be chunked which means split up into multiple calls.

FYI chunked Transfer-Encoding is superseded in HTTP/2: 
http://undertow.io/blog/2015/04/27/An-in-depth-overview-of-HTTP2.html

Info on HTTP chunked encoding:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding

Transfer-Encoding: chunked



  Data is sent in a series of chunks. The Content-Length header is
  omitted in this case and at the beginning of each chunk you need to
  add the length of the current chunk in hexadecimal format, followed by
  '\r\n' and then the chunk itself, followed by another '\r\n'. The
  terminating chunk is a regular chunk, with the exception that its
  length is zero. It is followed by the trailer, which consists of a
  (possibly empty) sequence of entity header fields.


https://www.httpwatch.com/httpgallery/chunked/

https://gist.github.com/CMCDragonkai/6bfade6431e9ffb7fe88


  Transfer-Encoding
  
  The use of Transfer-Encoding: chunked is what allows streaming within
  a single request or response. This means that the data is transmitted
  in a chunked manner, and does not impact the representation of the
  content.
  
  Officially an HTTP client is meant to send a request with a TE header
  field that specifies what kinds of transfer encodings the client is
  willing to accept. This is not always sent, however most servers
  assume that clients can process chunked encodings.
  
  The chunked transfer encoding makes better use of persistent TCP
  connections, which HTTP 1.1 assumes to be true by default.
  
  Chunked data is represented in this manner:


4\r\n
Wiki\r\n
5\r\n
pedia\r\n
e\r\n
 in\r\n\r\nchunks.\r\n
0\r\n
\r\n



  Each chunk starts with its byte length expressed as a hexadecimal
  number followed by optional parameters (chunk extension) and a
  terminating CRLF sequence, followed by the chunk data. The final chunk
  is terminated by a CRLF sequence.
  
  Chunk extensions can be used to indicate a message digest or an
  estimated progress. They are just custom metadata that your layer 7
  receiver needs to parse. There's no standardised format for it.
  Because of this, it's probably better to just add your metadata (if
  any) into the chunk itself for your layer 7.5 application to parse.
  
  For your application to send out chunked data, you must first send out
  the Transfer-Encoding header, and then you must flush content in
  chunks according to the chunk format. If you don't have an appropriate
  HTTP server that handles this, then you need to implement the syntax
  generator yourself. Sometimes you can use a library to provide an
  abstract interface.


Possible fix on Arduino platforms is to use StreamLib library or roll-your-own chunking system.

Update:  I hacked together a sketch and confirmed this works.  Next issue was the buffer must be null terminated, BUT this is stripped out before transmitted over TCP so the HTTP chunk size is the buffer size -1.