Update 2024-04-17-expect-the-unexpected.md

Author: delgreco

_posts/2024-04-17-expect-the-unexpected.md

@@ -8,7 +8,7 @@ Friends, your author gets perplexed more easily than you might suspect.  When a
 
 Inside this mental box, I couldn't believe these client calls were even making it to my server.  What's a hang?  It's the network, of course.  It's always the network, when things are hanging.  Right?
 
-After careful research (okay fine, after a conversation with chatGPT and various AIs) I arrived at the following effective `tcpdump` command with human readable output, and I was able to see...
+After careful research (okay fine, after a conversation with chatGPT and various AIs) I arrived at the following effective *tcpdump* command with human readable output, and I was able to see...
 
 ```
 sudo tcpdump -i [network interface] -n -t -vv -X -A src [IP address]
@@ -26,7 +26,7 @@ I wasn't familiar with this.  Developer.mozilla.org says:
 
 >The HTTP 100 Continue informational status response code indicates that everything so far is OK and that the client should continue with the request or ignore it if it is already finished.
 
-Apparently this has wide browser support and is generally not a nuisance.  But as it happens, the Microsoft .NET client (making the calls from our commercial system) behaves in a default manner incompatible with Apache's implementation of the 100-continue message (I'm running httpd 2.4.6).  This is all immortalized in  [the Stack Overflow question](https://stackoverflow.com/questions/3889574/apache-and-mod-proxy-not-handling-http-100-continue-from-client-http-417) where brave developers before me struggled with and finally slew the dragon by applying the hacky strategy of simply stripping the `Expect: 100-continue` header early enough in the request cycle to allow Apache to ignore it:
+Apparently this has wide browser support and is generally not a nuisance.  But as it happens, the Microsoft .NET client (making the calls from our commercial system) behaves in a default manner incompatible with Apache's implementation of the 100-continue message (I'm running httpd 2.4.6).  This is all immortalized in  [the Stack Overflow question](https://stackoverflow.com/questions/3889574/apache-and-mod-proxy-not-handling-http-100-continue-from-client-http-417) where brave developers before me struggled with and finally slew the dragon by applying the hacky strategy of simply stripping the *Expect: 100-continue* header early enough in the request cycle to allow Apache to ignore it:
 
 ```
 # this was placed in the Apache config file