Move file serving to HttpResponse

[Stormhand]

I moved the file read/send part from HttpServerTask::processRequest to:

void HttpResponse::sendFile(std::string fileName, size_t bufSize=4*1024)

so in the handler of my code im currently using:

static void webUiHandler(HttpRequest* pRequest, HttpResponse* pResponse) {
	if (pRequest->isWebsocket()){
		pRequest->getWebSocket()->close(HttpResponse::HTTP_STATUS_METHOD_NOT_ALLOWED, "NOT_ALLOWED");
	} else {
		pResponse->setStatus(HttpResponse::HTTP_STATUS_OK, "OK");
		pResponse->addHeader(HttpRequest::HTTP_HEADER_CONTENT_TYPE, "text/html");
		pResponse->sendFile("/spiffs/index.html");
		pResponse->close();
	}
}
.....
pHttpServer->addPathHandler(HttpRequest::HTTP_METHOD_GET, "/", webUiHandler);

Its some kind of redirect and i didnt find any other way to do it. I prepared a pull request

[nkolban]

Thank you sir. My philosophy on merge requests is to merge them ASAP. I personally don't like it when maintainers sit on pull requests for weeks/months ... so I try and merge as quickly as possible. This means that the onus moves to the chap making the request to ensure it works ... but with GIT, if something should ever go wrong, we can always back it out.

Looking forward to working with you on an on-going basis. You can always find me live on IRC in channel #ESP32 as user kolban.

[Stormhand]

Thank you, Neil. I would like to hear opinions from someone using it. Also, im planning to implement a redirect map to avoid implementing too many handlers.

[nkolban]

Its all good. My hope is to act as "moderator" and "steward" and let the community as a whole organically determine what is needed. If someone comes to me and says "Please add such and such a feature" ... then if I can and it doesn't have conflict with an existing feature then I will. Conversely, if a community member simply "wishes" to make a change and the above hold true ... then all good. Occasionally a change might be made that is either in conflict with existing code or in conflict with high level design aspects or technically broken ... those are likely the only times it would be right for me to put on a steward hat and see what we can do as a team.

There may come a time when there project reaches a critical mass where community members tell me that this current notion is no-longer workable. For example, if you yourself start using the library in your projects and a 3rd party makes a change that breaks your logic ... you might be concerned. Or, as is more likely, an API change is made that requires fixup in your code. If we ever reach that level of story, then we'll change our considerations and place more "process" on the game .. but as of right now. Simply go for it and have fun.

If EVER you wish to shoot the breeze on the project ... I'll always be here. Should you find code you don't understand ... its my role to figure it out and explain it. If you have decision choices and want a friendly voice to chat with ... that would be me.