##// END OF EJS Templates
hgweb: also set Content-Type header...
hgweb: also set Content-Type header Our HTTP/WSGI server may convert the Content-Type HTTP request header to the CONTENT_TYPE WSGI environment key and not set HTTP_CONTENT_TYPE. Other WSGI server implementations do this, so I think the behavior is acceptable. So assuming this HTTP request header could get "lost" by the WSGI server, let's restore it on the request object like we do for Content-Length. FWIW, the WSGI server may also *invent* a Content-Type value. The default behavior of Python's RFC 822 message class returns a default media type if Content-Type isn't defined. This is kind of annoying. But RFC 7231 section 3.1.1.5 does say the recipient may assume a media type of application/octet-stream. Python's defaults are for text/plain (given we're using an RFC 822 parser). But whatever. Differential Revision: https://phab.mercurial-scm.org/D2849

File last commit:

r33927:f4433f27 default
r37067:55e90139 default
Show More
compat.h
45 lines | 849 B | text/x-c | CLexer
#ifndef _HG_COMPAT_H_
#define _HG_COMPAT_H_
#ifdef _WIN32
#ifdef _MSC_VER
/* msvc 6.0 has problems */
#define inline __inline
#if defined(_WIN64)
typedef __int64 ssize_t;
typedef unsigned __int64 uintptr_t;
#else
typedef int ssize_t;
typedef unsigned int uintptr_t;
#endif
typedef signed char int8_t;
typedef short int16_t;
typedef long int32_t;
typedef __int64 int64_t;
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned long uint32_t;
typedef unsigned __int64 uint64_t;
#else
#include <stdint.h>
#endif
#else
/* not windows */
#include <sys/types.h>
#if defined __BEOS__ && !defined __HAIKU__
#include <ByteOrder.h>
#else
#include <arpa/inet.h>
#endif
#include <inttypes.h>
#endif
#if defined __hpux || defined __SUNPRO_C || defined _AIX
#define inline
#endif
#ifdef __linux
#define inline __inline
#endif
#endif