Stablizing cloud-nginx-proxy's HTTPS features
• Mark Eschbach
Back to getting the nginx proxy working in a functional way. System level behavioral tests are really the key to my confidence when I deploy this thing. Currently I have one failure around HTTPS not honoring upload overrides. Simple enough to begin working on. Looking at the generated output in the error log it is indeed missing the location
directive for /example-uplaod
. Time to dive into the details of the generator to find out why.
The root of the failure is derefercing a nil
value in the then
step. The then
step is still using my older style of searching via regex. I think it might be time to upgrade the step. A small amount of time has passed since I’ve worked on this the assertions library. I use @host_config
to represent the raw text generated by the system. @conf
is used by the tests for the results of MEE::Nginx::Parser
. I’ll probably want to use an adaption of this line after filtering the blocks for our target server. I think I might want to expand the resulting parser tree to be more intelligent since finding a specific server is something cloud-nginx-proxy
should be doing often. TODO
In order to prevent breaking all current tests the best approach might be to put an if
checking if the variable @config
exists. If it does then I should probably prefer that than the regular expressions I was using previously. After I get the suite stablized I want to come back to the regex and get ride of the dependency on it. There may be a better approach, as in not modifying the assertion because it’s not necessarily wrong at this point but should be changed in the future. Since the text the regex was attempting to match is missing I should probably attack that problem first.
With EtcDv2 I completely overlooked the location directive which is probably where I left off. Score another one for test driven development in that it told me where to resume. Well, I made forward progress by causing the tests to fail while creating the location with the host. I’ve got to think about the best way to represent that path like format of /images/upload
and such. I’ve exhausted this block of time to work on this problem. I’ll have to return later after reflecting on the problems I’ve encountered here.