诸暨麻将添加redis
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

701 lines
22 KiB

  1. _ _ ____ _
  2. ___| | | | _ \| |
  3. / __| | | | |_) | |
  4. | (__| |_| | _ <| |___
  5. \___|\___/|_| \_\_____|
  6. Things that could be nice to do in the future
  7. Things to do in project cURL. Please tell us what you think, contribute and
  8. send us patches that improve things!
  9. All bugs documented in the KNOWN_BUGS document are subject for fixing!
  10. 1. libcurl
  11. 1.2 More data sharing
  12. 1.3 struct lifreq
  13. 1.4 signal-based resolver timeouts
  14. 1.5 get rid of PATH_MAX
  15. 1.6 Happy Eyeball dual stack connect
  16. 1.7 Modified buffer size approach
  17. 2. libcurl - multi interface
  18. 2.1 More non-blocking
  19. 2.2 Fix HTTP Pipelining for PUT
  20. 3. Documentation
  21. 3.1 More and better
  22. 4. FTP
  23. 4.1 HOST
  24. 4.2 Alter passive/active on failure and retry
  25. 4.3 Earlier bad letter detection
  26. 4.4 REST for large files
  27. 4.5 FTP proxy support
  28. 4.6 ASCII support
  29. 5. HTTP
  30. 5.1 Better persistency for HTTP 1.0
  31. 5.2 support FF3 sqlite cookie files
  32. 5.3 Rearrange request header order
  33. 5.4 HTTP2/SPDY
  34. 6. TELNET
  35. 6.1 ditch stdin
  36. 6.2 ditch telnet-specific select
  37. 6.3 feature negotiation debug data
  38. 6.4 send data in chunks
  39. 7. SMTP
  40. 7.1 Pipelining
  41. 7.2 Graceful base64 decoding failure
  42. 7.3 Enhanced capability support
  43. 8. POP3
  44. 8.1 Pipelining
  45. 8.2 Graceful base64 decoding failure
  46. 8.3 Enhanced capability support
  47. 9. IMAP
  48. 9.1 Graceful base64 decoding failure
  49. 9.2 Enhanced capability support
  50. 10. LDAP
  51. 10.1 SASL based authentication mechanisms
  52. 11. New protocols
  53. 11.1 RSYNC
  54. 12. SSL
  55. 12.1 Disable specific versions
  56. 12.2 Provide mutex locking API
  57. 12.3 Evaluate SSL patches
  58. 12.4 Cache OpenSSL contexts
  59. 12.5 Export session ids
  60. 12.6 Provide callback for cert verification
  61. 12.7 Support other SSL libraries
  62. 12.8 improve configure --with-ssl
  63. 12.9 Support DANE
  64. 13. GnuTLS
  65. 13.1 SSL engine stuff
  66. 13.2 check connection
  67. 14. SASL
  68. 14.1 Other authentication mechanisms
  69. 15. Client
  70. 15.1 sync
  71. 15.2 glob posts
  72. 15.3 prevent file overwriting
  73. 15.4 simultaneous parallel transfers
  74. 15.5 provide formpost headers
  75. 15.6 url-specific options
  76. 15.7 warning when setting an option
  77. 15.8 IPv6 addresses with globbing
  78. 16. Build
  79. 16.1 roffit
  80. 17. Test suite
  81. 17.1 SSL tunnel
  82. 17.2 nicer lacking perl message
  83. 17.3 more protocols supported
  84. 17.4 more platforms supported
  85. 18. Next SONAME bump
  86. 18.1 http-style HEAD output for ftp
  87. 18.2 combine error codes
  88. 18.3 extend CURLOPT_SOCKOPTFUNCTION prototype
  89. 19. Next major release
  90. 19.1 cleanup return codes
  91. 19.2 remove obsolete defines
  92. 19.3 size_t
  93. 19.4 remove several functions
  94. 19.5 remove CURLOPT_FAILONERROR
  95. 19.6 remove CURLOPT_DNS_USE_GLOBAL_CACHE
  96. 19.7 remove progress meter from libcurl
  97. 19.8 remove 'curl_httppost' from public
  98. 19.9 have form functions use CURL handle argument
  99. 19.10 Add CURLOPT_MAIL_CLIENT option
  100. ==============================================================================
  101. 1. libcurl
  102. 1.2 More data sharing
  103. curl_share_* functions already exist and work, and they can be extended to
  104. share more. For example, enable sharing of the ares channel and the
  105. connection cache.
  106. 1.3 struct lifreq
  107. Use 'struct lifreq' and SIOCGLIFADDR instead of 'struct ifreq' and
  108. SIOCGIFADDR on newer Solaris versions as they claim the latter is obsolete.
  109. To support ipv6 interface addresses for network interfaces properly.
  110. 1.4 signal-based resolver timeouts
  111. libcurl built without an asynchronous resolver library uses alarm() to time
  112. out DNS lookups. When a timeout occurs, this causes libcurl to jump from the
  113. signal handler back into the library with a sigsetjmp, which effectively
  114. causes libcurl to continue running within the signal handler. This is
  115. non-portable and could cause problems on some platforms. A discussion on the
  116. problem is available at http://curl.haxx.se/mail/lib-2008-09/0197.html
  117. Also, alarm() provides timeout resolution only to the nearest second. alarm
  118. ought to be replaced by setitimer on systems that support it.
  119. 1.5 get rid of PATH_MAX
  120. Having code use and rely on PATH_MAX is not nice:
  121. http://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html
  122. Currently the SSH based code uses it a bit, but to remove PATH_MAX from there
  123. we need libssh2 to properly tell us when we pass in a too small buffer and
  124. its current API (as of libssh2 1.2.7) doesn't.
  125. 1.6 Happy Eyeball dual stack connect
  126. In order to make alternative technologies not suffer when transitioning, like
  127. when introducing IPv6 as an alternative to IPv4 and there are more than one
  128. option existing simultaneously there are reasons to reconsider internal
  129. choices.
  130. To make libcurl do blazing fast IPv6 in a dual-stack configuration, this needs
  131. to be addressed:
  132. http://tools.ietf.org/html/rfc6555
  133. 1.7 Modified buffer size approach
  134. Current libcurl allocates a fixed 16K size buffer for download and an
  135. additional 16K for upload. They are always unconditionally part of the easy
  136. handle. If CRLF translations are requested, an additional 32K "scratch
  137. buffer" is allocated. A total of 64K transfer buffers in the worst case.
  138. First, while the handles are not actually in use these buffers could be freed
  139. so that lingering handles just kept in queues or whatever waste less memory.
  140. Secondly, SFTP is a protocol that needs to handle many ~30K blocks at once
  141. since each need to be individually acked and therefore libssh2 must be
  142. allowed to send (or receive) many separate ones in parallel to achieve high
  143. transfer speeds. A current libcurl build with a 16K buffer makes that
  144. impossible, but one with a 512K buffer will reach MUCH faster transfers. But
  145. allocating 512K unconditionally for all buffers just in case they would like
  146. to do fast SFTP transfers at some point is not a good solution either.
  147. Dynamically allocate buffer size depending on protocol in use in combination
  148. with freeing it after each individual transfer? Other suggestions?
  149. 2. libcurl - multi interface
  150. 2.1 More non-blocking
  151. Make sure we don't ever loop because of non-blocking sockets returning
  152. EWOULDBLOCK or similar. Blocking cases include:
  153. - Name resolves on non-windows unless c-ares is used
  154. - NSS SSL connections
  155. - HTTP proxy CONNECT operations
  156. - SOCKS proxy handshakes
  157. - file:// transfers
  158. - TELNET transfers
  159. - The "DONE" operation (post transfer protocol-specific actions) for the
  160. protocols SFTP, SMTP, FTP. Fixing Curl_done() for this is a worthy task.
  161. 2.2 Fix HTTP Pipelining for PUT
  162. HTTP Pipelining can be a way to greatly enhance performance for multiple
  163. serial requests and currently libcurl only supports that for HEAD and GET
  164. requests but it should also be possible for PUT.
  165. 3. Documentation
  166. 3.1 More and better
  167. Exactly
  168. 4. FTP
  169. 4.1 HOST
  170. HOST is a suggested command in the works for a client to tell which host name
  171. to use, to offer FTP servers named-based virtual hosting:
  172. http://tools.ietf.org/html/draft-hethmon-mcmurray-ftp-hosts-11
  173. 4.2 Alter passive/active on failure and retry
  174. When trying to connect passively to a server which only supports active
  175. connections, libcurl returns CURLE_FTP_WEIRD_PASV_REPLY and closes the
  176. connection. There could be a way to fallback to an active connection (and
  177. vice versa). http://curl.haxx.se/bug/feature.cgi?id=1754793
  178. 4.3 Earlier bad letter detection
  179. Make the detection of (bad) %0d and %0a codes in FTP url parts earlier in the
  180. process to avoid doing a resolve and connect in vain.
  181. 4.4 REST for large files
  182. REST fix for servers not behaving well on >2GB requests. This should fail if
  183. the server doesn't set the pointer to the requested index. The tricky
  184. (impossible?) part is to figure out if the server did the right thing or not.
  185. 4.5 FTP proxy support
  186. Support the most common FTP proxies, Philip Newton provided a list allegedly
  187. from ncftp. This is not a subject without debate, and is probably not really
  188. suitable for libcurl. http://curl.haxx.se/mail/archive-2003-04/0126.html
  189. 4.6 ASCII support
  190. FTP ASCII transfers do not follow RFC959. They don't convert the data
  191. accordingly.
  192. 5. HTTP
  193. 5.1 Better persistency for HTTP 1.0
  194. "Better" support for persistent connections over HTTP 1.0
  195. http://curl.haxx.se/bug/feature.cgi?id=1089001
  196. 5.2 support FF3 sqlite cookie files
  197. Firefox 3 is changing from its former format to a a sqlite database instead.
  198. We should consider how (lib)curl can/should support this.
  199. http://curl.haxx.se/bug/feature.cgi?id=1871388
  200. 5.3 Rearrange request header order
  201. Server implementors often make an effort to detect browser and to reject
  202. clients it can detect to not match. One of the last details we cannot yet
  203. control in libcurl's HTTP requests, which also can be exploited to detect
  204. that libcurl is in fact used even when it tries to impersonate a browser, is
  205. the order of the request headers. I propose that we introduce a new option in
  206. which you give headers a value, and then when the HTTP request is built it
  207. sorts the headers based on that number. We could then have internally created
  208. headers use a default value so only headers that need to be moved have to be
  209. specified.
  210. 5.4 HTTP2/SPDY
  211. The first drafts for HTTP2 have been published
  212. (http://tools.ietf.org/html/draft-ietf-httpbis-http2-03) and is so far based
  213. on SPDY (http://www.chromium.org/spdy) designs and experiences. Chances are
  214. it will end up in that style. Chrome and Firefox already support SPDY and
  215. lots of web services do.
  216. It would make sense to implement SPDY support now and later transition into
  217. or add HTTP2 support as well.
  218. We should base or HTTP2/SPDY work on a 3rd party library for the protocol
  219. fiddling. The Spindy library (http://spindly.haxx.se/) was an attempt to make
  220. such a library with an API suitable for use by libcurl but that effort has
  221. more or less stalled. spdylay (https://github.com/tatsuhiro-t/spdylay) may
  222. be a better option, either used directly or wrapped with a more spindly-like
  223. API.
  224. 6. TELNET
  225. 6.1 ditch stdin
  226. Reading input (to send to the remote server) on stdin is a crappy solution for
  227. library purposes. We need to invent a good way for the application to be able
  228. to provide the data to send.
  229. 6.2 ditch telnet-specific select
  230. Move the telnet support's network select() loop go away and merge the code
  231. into the main transfer loop. Until this is done, the multi interface won't
  232. work for telnet.
  233. 6.3 feature negotiation debug data
  234. Add telnet feature negotiation data to the debug callback as header data.
  235. 6.4 send data in chunks
  236. Currently, telnet sends data one byte at a time. This is fine for interactive
  237. use, but inefficient for any other. Sent data should be sent in larger
  238. chunks.
  239. 7. SMTP
  240. 7.1 Pipelining
  241. Add support for pipelining emails.
  242. 7.2 Graceful base64 decoding failure
  243. Rather than shutting down the session and returning an error when the
  244. decoding of a base64 encoded authentication response fails, we should
  245. gracefully shutdown the authentication process by sending a * response to the
  246. server as per RFC4954.
  247. 7.3 Enhanced capability support
  248. Add the ability, for an application that uses libcurl, to obtain the list of
  249. capabilities returned from the EHLO command.
  250. 8. POP3
  251. 8.1 Pipelining
  252. Add support for pipelining commands.
  253. 8.2 Graceful base64 decoding failure
  254. Rather than shutting down the session and returning an error when the
  255. decoding of a base64 encoded authentication response fails, we should
  256. gracefully shutdown the authentication process by sending a * response to the
  257. server as per RFC5034.
  258. 8.3 Enhanced capability support
  259. Add the ability, for an application that uses libcurl, to obtain the list of
  260. capabilities returned from the CAPA command.
  261. 9. IMAP
  262. 9.1 Graceful base64 decoding failure
  263. Rather than shutting down the session and returning an error when the
  264. decoding of a base64 encoded authentication response fails, we should
  265. gracefully shutdown the authentication process by sending a * response to the
  266. server as per RFC3501.
  267. 9.2 Enhanced capability support
  268. Add the ability, for an application that uses libcurl, to obtain the list of
  269. capabilities returned from the CAPABILITY command.
  270. 10. LDAP
  271. 10.1 SASL based authentication mechanisms
  272. Currently the LDAP module only supports ldap_simple_bind_s() in order to bind
  273. to an LDAP server. However, this function sends username and password details
  274. using the simple authentication mechanism (as clear text). However, it should
  275. be possible to use ldap_bind_s() instead specifing the security context
  276. information ourselves.
  277. 11. New protocols
  278. 11.1 RSYNC
  279. There's no RFC for the protocol or an URI/URL format. An implementation
  280. should most probably use an existing rsync library, such as librsync.
  281. 12. SSL
  282. 12.1 Disable specific versions
  283. Provide an option that allows for disabling specific SSL versions, such as
  284. SSLv2 http://curl.haxx.se/bug/feature.cgi?id=1767276
  285. 12.2 Provide mutex locking API
  286. Provide a libcurl API for setting mutex callbacks in the underlying SSL
  287. library, so that the same application code can use mutex-locking
  288. independently of OpenSSL or GnutTLS being used.
  289. 12.3 Evaluate SSL patches
  290. Evaluate/apply Gertjan van Wingerde's SSL patches:
  291. http://curl.haxx.se/mail/lib-2004-03/0087.html
  292. 12.4 Cache OpenSSL contexts
  293. "Look at SSL cafile - quick traces look to me like these are done on every
  294. request as well, when they should only be necessary once per ssl context (or
  295. once per handle)". The major improvement we can rather easily do is to make
  296. sure we don't create and kill a new SSL "context" for every request, but
  297. instead make one for every connection and re-use that SSL context in the same
  298. style connections are re-used. It will make us use slightly more memory but
  299. it will libcurl do less creations and deletions of SSL contexts.
  300. 12.5 Export session ids
  301. Add an interface to libcurl that enables "session IDs" to get
  302. exported/imported. Cris Bailiff said: "OpenSSL has functions which can
  303. serialise the current SSL state to a buffer of your choice, and recover/reset
  304. the state from such a buffer at a later date - this is used by mod_ssl for
  305. apache to implement and SSL session ID cache".
  306. 12.6 Provide callback for cert verification
  307. OpenSSL supports a callback for customised verification of the peer
  308. certificate, but this doesn't seem to be exposed in the libcurl APIs. Could
  309. it be? There's so much that could be done if it were!
  310. 12.7 Support other SSL libraries
  311. Make curl's SSL layer capable of using other free SSL libraries. Such as
  312. MatrixSSL (http://www.matrixssl.org/).
  313. 12.8 improve configure --with-ssl
  314. make the configure --with-ssl option first check for OpenSSL, then GnuTLS,
  315. then NSS...
  316. 12.9 Support DANE
  317. DNS-Based Authentication of Named Entities (DANE) is a way to provide SSL
  318. keys and certs over DNS using DNSSEC as an alternative to the CA model.
  319. http://www.rfc-editor.org/rfc/rfc6698.txt
  320. An initial patch was posted by Suresh Krishnaswamy on March 7th 2013
  321. (http://curl.haxx.se/mail/lib-2013-03/0075.html) but it was a too simple
  322. approach. See Daniel's comments:
  323. http://curl.haxx.se/mail/lib-2013-03/0103.html . libunbound may be the
  324. correct library to base this development on.
  325. 13. GnuTLS
  326. 13.1 SSL engine stuff
  327. Is this even possible?
  328. 13.2 check connection
  329. Add a way to check if the connection seems to be alive, to correspond to the
  330. SSL_peak() way we use with OpenSSL.
  331. 14. SASL
  332. 14.1 Other authentication mechanisms
  333. Add support for GSSAPI to SMTP, POP3 and IMAP.
  334. 15. Client
  335. 15.1 sync
  336. "curl --sync http://example.com/feed[1-100].rss" or
  337. "curl --sync http://example.net/{index,calendar,history}.html"
  338. Downloads a range or set of URLs using the remote name, but only if the
  339. remote file is newer than the local file. A Last-Modified HTTP date header
  340. should also be used to set the mod date on the downloaded file.
  341. 15.2 glob posts
  342. Globbing support for -d and -F, as in 'curl -d "name=foo[0-9]" URL'.
  343. This is easily scripted though.
  344. 15.3 prevent file overwriting
  345. Add an option that prevents cURL from overwriting existing local files. When
  346. used, and there already is an existing file with the target file name
  347. (either -O or -o), a number should be appended (and increased if already
  348. existing). So that index.html becomes first index.html.1 and then
  349. index.html.2 etc.
  350. 15.4 simultaneous parallel transfers
  351. The client could be told to use maximum N simultaneous parallel transfers and
  352. then just make sure that happens. It should of course not make more than one
  353. connection to the same remote host. This would require the client to use the
  354. multi interface. http://curl.haxx.se/bug/feature.cgi?id=1558595
  355. 15.5 provide formpost headers
  356. Extending the capabilities of the multipart formposting. How about leaving
  357. the ';type=foo' syntax as it is and adding an extra tag (headers) which
  358. works like this: curl -F "coolfiles=@fil1.txt;headers=@fil1.hdr" where
  359. fil1.hdr contains extra headers like
  360. Content-Type: text/plain; charset=KOI8-R"
  361. Content-Transfer-Encoding: base64
  362. X-User-Comment: Please don't use browser specific HTML code
  363. which should overwrite the program reasonable defaults (plain/text,
  364. 8bit...)
  365. 15.6 url-specific options
  366. Provide a way to make options bound to a specific URL among several on the
  367. command line. Possibly by letting ':' separate options between URLs,
  368. similar to this:
  369. curl --data foo --url url.com : \
  370. --url url2.com : \
  371. --url url3.com --data foo3
  372. (More details: http://curl.haxx.se/mail/archive-2004-07/0133.html)
  373. The example would do a POST-GET-POST combination on a single command line.
  374. 15.7 warning when setting an option
  375. Display a warning when libcurl returns an error when setting an option.
  376. This can be useful to tell when support for a particular feature hasn't been
  377. compiled into the library.
  378. 15.8 IPv6 addresses with globbing
  379. Currently the command line client needs to get url globbing disabled (with
  380. -g) for it to support IPv6 numerical addresses. This is a rather silly flaw
  381. that should be corrected. It probably involves a smarter detection of the
  382. '[' and ']' letters.
  383. 16. Build
  384. 16.1 roffit
  385. Consider extending 'roffit' to produce decent ASCII output, and use that
  386. instead of (g)nroff when building src/tool_hugehelp.c
  387. 17. Test suite
  388. 17.1 SSL tunnel
  389. Make our own version of stunnel for simple port forwarding to enable HTTPS
  390. and FTP-SSL tests without the stunnel dependency, and it could allow us to
  391. provide test tools built with either OpenSSL or GnuTLS
  392. 17.2 nicer lacking perl message
  393. If perl wasn't found by the configure script, don't attempt to run the tests
  394. but explain something nice why it doesn't.
  395. 17.3 more protocols supported
  396. Extend the test suite to include more protocols. The telnet could just do ftp
  397. or http operations (for which we have test servers).
  398. 17.4 more platforms supported
  399. Make the test suite work on more platforms. OpenBSD and Mac OS. Remove
  400. fork()s and it should become even more portable.
  401. 18. Next SONAME bump
  402. 18.1 http-style HEAD output for ftp
  403. #undef CURL_FTP_HTTPSTYLE_HEAD in lib/ftp.c to remove the HTTP-style headers
  404. from being output in NOBODY requests over ftp
  405. 18.2 combine error codes
  406. Combine some of the error codes to remove duplicates. The original
  407. numbering should not be changed, and the old identifiers would be
  408. macroed to the new ones in an CURL_NO_OLDIES section to help with
  409. backward compatibility.
  410. Candidates for removal and their replacements:
  411. CURLE_FILE_COULDNT_READ_FILE => CURLE_REMOTE_FILE_NOT_FOUND
  412. CURLE_FTP_COULDNT_RETR_FILE => CURLE_REMOTE_FILE_NOT_FOUND
  413. CURLE_FTP_COULDNT_USE_REST => CURLE_RANGE_ERROR
  414. CURLE_FUNCTION_NOT_FOUND => CURLE_FAILED_INIT
  415. CURLE_LDAP_INVALID_URL => CURLE_URL_MALFORMAT
  416. CURLE_TFTP_NOSUCHUSER => CURLE_TFTP_ILLEGAL
  417. CURLE_TFTP_NOTFOUND => CURLE_REMOTE_FILE_NOT_FOUND
  418. CURLE_TFTP_PERM => CURLE_REMOTE_ACCESS_DENIED
  419. 18.3 extend CURLOPT_SOCKOPTFUNCTION prototype
  420. The current prototype only provides 'purpose' that tells what the
  421. connection/socket is for, but not any protocol or similar. It makes it hard
  422. for applications to differentiate on TCP vs UDP and even HTTP vs FTP and
  423. similar.
  424. 10. Next major release
  425. 19.1 cleanup return codes
  426. curl_easy_cleanup() returns void, but curl_multi_cleanup() returns a
  427. CURLMcode. These should be changed to be the same.
  428. 19.2 remove obsolete defines
  429. remove obsolete defines from curl/curl.h
  430. 19.3 size_t
  431. make several functions use size_t instead of int in their APIs
  432. 19.4 remove several functions
  433. remove the following functions from the public API:
  434. curl_getenv
  435. curl_mprintf (and variations)
  436. curl_strequal
  437. curl_strnequal
  438. They will instead become curlx_ - alternatives. That makes the curl app
  439. still capable of using them, by building with them from source.
  440. These functions have no purpose anymore:
  441. curl_multi_socket
  442. curl_multi_socket_all
  443. 19.5 remove CURLOPT_FAILONERROR
  444. Remove support for CURLOPT_FAILONERROR, it has gotten too kludgy and weird
  445. internally. Let the app judge success or not for itself.
  446. 19.6 remove CURLOPT_DNS_USE_GLOBAL_CACHE
  447. Remove support for a global DNS cache. Anything global is silly, and we
  448. already offer the share interface for the same functionality but done
  449. "right".
  450. 19.7 remove progress meter from libcurl
  451. The internally provided progress meter output doesn't belong in the library.
  452. Basically no application wants it (apart from curl) but instead applications
  453. can and should do their own progress meters using the progress callback.
  454. The progress callback should then be bumped as well to get proper 64bit
  455. variable types passed to it instead of doubles so that big files work
  456. correctly.
  457. 19.8 remove 'curl_httppost' from public
  458. curl_formadd() was made to fill in a public struct, but the fact that the
  459. struct is public is never really used by application for their own advantage
  460. but instead often restricts how the form functions can or can't be modified.
  461. Changing them to return a private handle will benefit the implementation and
  462. allow us much greater freedoms while still maintining a solid API and ABI.
  463. 19.9 have form functions use CURL handle argument
  464. curl_formadd() and curl_formget() both currently have no CURL handle
  465. argument, but both can use a callback that is set in the easy handle, and
  466. thus curl_formget() with callback cannot function without first having
  467. curl_easy_perform() (or similar) called - which is hard to grasp and a design
  468. mistake.
  469. 19.10 Add CURLOPT_MAIL_CLIENT option
  470. Rather than use the URL to specify the mail client string to present in the
  471. HELO and EHLO commands, libcurl should support a new CURLOPT specifically for
  472. specifing this data as the URL is non-standard and to be honest a bit of a
  473. hack ;-)
  474. Please see the following thread for more information:
  475. http://curl.haxx.se/mail/lib-2012-05/0178.html